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ABSTRACT 

The  Computer  Performance  Modeling  Tool  (CPMT)  is  a 
queueing  network  simulator  to  be  used  in  support  of  Computer 
Performance  and  Evaluation  courses  like  CS4400.  This  thesis 
is  a  continuation  of  the  CPMT  development  project  and 
consists  of  adaptive  and  perfective  maintenance  work  to 
modify  the  existing  simulator  to  add  extended  modeling 
capability  and  to  improve  the  simulator  performance.  The 
thesis  effort  also  included  rewriting  the  CPMT  user's  manual 
to  reflect  new  features,  establishing  a  change  log  for  the 
program  and  continuing  validation  of  the  simulator. 
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I-  M2  BO  MICTION 

The  Computer  Performance  Modeling  Tool  (CPMT)  is  a 
gueueing  network  simulator  designed  to  model  computer 
systems,  and  it  is  written  in  PASCAL  for  the  VAX-11/VMS 
environment. 

This  thesis  describes  a  development  and  enhancement 
effort  to  improve  the  performance  and  modeling  capability  of 
the  CEMT  simulator. 

A.   BACKGEOOND 

1  •   Overview   of   the  Computer   Performance   Evaluation 
Methods 

The  application  of  computer  performance  and 
evaluation  includes  the  analysis  and  enhancement  of 
performance  of  existing  systems  and  the  prediction  of 
performance  of  planned  or  projected  systems.  Performance  of 
existing  systems  can  be  evaluated  via  measurements,  using 
hardware  and/or  software  monitors,  either  in  a  user 
environment  or  under  benchmark  conditions.  However,  the 
interactions  in  present  day  computer  systems  are  so  complex 
that  some  form  cf  modeling  is  necessary  in  order  to  tune, 
predict,  and  understand  computer  system  performance. 
Performance  modeling  is  also  widely  used  during  design  and 
development  of  new  systems. 

Networks  of  queues  and  Markov  chains  are  the  most 
common  representations  of  computer  systems.  Queueing  models 
are  analyzed  by  mathematical  techniques  employing  applied 
probability  theory  £Bef.  1 ]. 

The  increased  complexity  of  many  computer  systems 
models,    as  a   result  of   inclusion   of  different   resource 
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scheduling  algorithms,  makes  the  design  of  models  difficult 
and  makes  the  utilization  of  mathematical  analysis 
unreasonable.  In  such  cases  it  is  necessary  to  use  a  system 
simulation.  A  system  simulation  implies  the  generation  of 
random  inputs  and  the  monitoring  of  distinct  events  in  the 
modeled  system.  Once  a  model  has  been  formulated,  a 
simulator  run  tracks  the  execution  of  the  model  as 
determined  by  the  occurrence  of  events  at  discrete  time 
instants.  The  output  of  the  simulation  are  random  variables. 
Therefore  statistical  analysis  must  be  performed  to  produce 
a  meaningful  statement  about  the  validity  of  the  sinulation 
results. 

2.   Computer  Performance  Modeling  Tool  (CPMT) 

CPMT  program  development  began  as  a  class  project 
for  the  Computer  System  Performance  Evaluation  course,  CS 
4400,  taught  at  the  Naval  Postgraduate  School. 

The  objectives  were  the  familiarization  of  students 
with  simulation  program  design,  and  to  produce  a  simulation 
program  which  could  be  used  within  the  class  context  to 
model  computer  systems.  The  class  effort  produced  the 
initial  program  design  and  two  program  modules.  The  CPMT 
development  task  was  then  the  topic  for  a  Master's  Thesis  by 
IT  Karen  Pagel  [Eef.  2].  The  product  of  this  effort  was  an 
operational,  documented  and  partially  tested  simulation 
program  ready  to  be  used  as  a  classroom  tool  for  CS  4400, 
and  as  a  basis  for  further  development  and  enhancement. 

This  thesis  is  a  continuation  of  the  overall  CPMT 
development  project,  and  consists  of  an  adaptive  and 
perfective  maintenance  effort  to  modify  the  existing 
simulator  to  add  extended  modeling  capabilities  and  to 
enhance  the  simulator  performance. 

The  thesis  effort  also  included  rewriting  the  user's 
manual  to  reflect   new  features,   establishing  a   change  log 
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for      the     CPMT      program  and      continuing      validation      of      the 
simulator. 

B.  OBJECTIVES 

The  initial  CPMT  program  was  operational  and  had  been 
used  as  part  of  a  class  exercise  for  CS  4400.  However,  from 
the  conclusions  listed  in  the  thesis  by  It  Pagel  [Bef.  2], 
some  weaknesses  were  detected  ty  program  designers  and  users 
which  justified  further  program  development.  From  those 
critics  and  analysis  cf  other  potential  improvements,  four 
major  types  of  requirements  were  identified  as  desirable 
areas  for  enhacenent:  program  efficiency,  user 
friendliness,  modeling  capability,  and  simulation  run 
flexibility. 

The  objective  cf  this  thesis  was  to  perform  a 
maintenance  effort  fccused  on  the  areas  described  above, 
taking  advantage  of  the  readability  and  modularity  of  the 
original  CPMT  program  and  its  complete  documentation. 

C.  TBESIS  OBGAHIZATICH 

Chapter  2,  Maintenance  Effort,  describes  the  maintenance 
process  and  is  concerned  with  WHAT  and  WHY  maintenance  was 
performed  on  the  CPMT  program.  It  discusses  limitations  of 
the  original  product  and  presents  the  additional 
requirements  and  program  enhancements  to  be  implemented 
through  the  maintenance  effort. 

Chapter  3,  Change  Log,  is  programming  oriented  and  is 
concerned  with  HOW  the  CPMT  program  was  changed  and  which 
additional  requirements  have  been  implemented,  and  it 
includes  a  description  of  the  design  considerations  involved 
and  the  code  affected. 

The  new  version  of  the  CPMT  user's  manual  is  provided  as 
Chapter  4  and   includes  a  description  and   examples  of  model 


13 


design  and  an  explanation  of  how  the  program  is  run. 
Testing  and  validation  of  the  CPMT  program  are  discussed  in 
Chapter  5.  Hypothetical  computer  systems  studies  have  been 
used  as  test  models  for  validation  of  the  simulator. 

The  conclusions  in  Chapter  6  present  the  current 
limitations  and  potential  enhancements  for  continuing  the 
CPMT  program  development. 
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II.    MAINTENANCE   IfZQRT 

A.  TTPE  OF  HAINTEHAHCE 

Program  maintenance  is  the  process  by  which  operational 
programs  are  corrected,  adapted  or  upgraded.  Adaptive 
maintenance  is  performed  to  modify  a  program  to  meet  changes 
or  expansion  of  specifications.  Perfective  maintenance  is 
performed  to  enhance  performance,  processing  efficiency  or 
maintainability  of  operational  programs.  Most  of  the 
maintenance  work  produced  for  the  CPMT  program  focused  on 
adaptive  and  perfective  maintenance  aspects.  Nevertheless, 
some  errors  in  the  original  program  were  discovered  and 
corrected  throughout  the  maintenance  process. 

B.  MAINTENANCE  PROCESS 

The  maintenance  process  was  developed  through  the 
following  phases: 

-analysis  of  requirements 

-review  of  program  design 

-translation  of  nev  design  into  code 

-testing 

-updating  of  documentation 

The  work  performed  during  these  phases  is  described  in 
the  following  sections. 
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C.   AKALISIS  OF  BEQDIBEMEHTS 

The  purpose  of  the  first  step  of  the  maintenance  process 
was  to  identify  and  analyze  the  desirable  requirements  for 
the  simulation  program  and  to  group  them  according  to  the 
maintenance  work  involved. 

The  following  groups  of  requirements  have  been  analyzed: 

-  Improvement  of  processing  efficiency 

-  Extension  of  modeling  capabilities 

-  Improvement  of  simulation  run  flexibility 

-  Enhancement  of  program  user  friendliness 
1  .   Improvement  of  Processing  E f ficien cy 

Cne  important  decision  in  a  simulator  design  is  the 
computer  space  and  time  required  to  run  computer  system 
models.  In  the  original  CPMT  design,  all  job  and  event 
records  which  describe  the  problem  to  be  processed  by  the 
simulation  are  created  before  starting  to  process  jobs 
through  the  simulated  system.  After  all  jobs  are  processed, 
the  program  traverses  the  list  of  job  records  to  calculate 
the  job  statistics.  This  design  decision  leads  to 
inefficient  use  of  memory  space.  Long  simulations  are  not 
possible  on  the  original  program  due  to  large  memory  space 
requirements. 

In  the  new  version  jobs  and  events  are  dynamically 
created  as  the  simulation  is  being  processed  and  there  is 
only  a  single  event  record  attached  to  each  job  at  any  time. 
Ihis  record  is  updated  whenever  a  new  event  for  that  job  is 
required.  Gathering  of  job  statistics  is  performed  as  jobs 
leave  the  system,  avoiding  long  lists,  and  allowing  jot  and 
event  records  to  be  released  when  they  complete. 
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2  -      Extension   of    Modeling    Capabi li t ies 

a.      Closed    Queueing    Networks 

One  of  the  major  advantages  of  simulation  is 
generality.  The  initial  version  of  the  CPiMT  program  can 
simulate  only  open  gueueing  network  uiodels.  These  models 
often  are  appropriate  for  communication  system  modeling  and 
sometimes  for  computer  systems  modeling  [ Ref .  3  :p.  234]. 
Open  networks  are  characterized  by  one  source  of  job 
arrivals  and  one  sink  that  absorbs  jobs  departing  frcm  the 
network,    as  shown   in    Fig    2.1. 
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Figure  2.1   Open  Queueing  Network 
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One  of  the  implicit  assumptions  behind  these 
models  is  that  immediately  upon  its  arrival,  a  jot  is 
scheduled  into  main  memory  and  is  able  to  compete  for 
resources  [Ref.  4  :p.423].  In  practice  the  number  of  main 
memory  partitions  in  a  computer  system  will  be  limited  which 
implies  the  existence  of  a  job  scheduler  queue.  For  a  large 
external  rate  of  arrival  of  jobs,  the  probability  that  there 
is  at  least  one  job  in  this  job  scheduler  queue  is  very 
high,  and  it  may  be  assumed  that  a  job  departure  immediately 
triggers  the  scheduling  of  an  already  waiting  job  into  main 
memory.  Ihis  situation  is  often  modeled  by  a  closed  gueueing 
network,  which  acts  as  if  the  departing  jobs  wrap  around  to 
the  input,  and  immediately  re-enter  the  system.  This  type  of 
network  is  shown  in  Fig  2.2  . 

Each  circulating  job  is  an  active  job  and  must 
be  allocated  a  specific  partition  of  main  memory,  and  the 
total  number  of  active  jobs  is  called  the  degree  of 
multiprogramming.  Closed  gueueing  network  models  have  been 
successfully  used  to  characterize  computer  systems  in  a 
multiprogramming  environment  [Ref.  3],  and  can  be  simulated 
in  the  new  CPHT  Simulator. 

1.   Alternative  Queueing  Disciplines 

A  gueueing  discipline  is  an  algorithm  that 
determines  the  order  in  which  the  jobs  in  queue  for  a 
servergroup  of  a  network  are  served.  A  weakness  of  the 
initial  version  of  the  simulator  is  that  no  provision  was 
made  for  selection  of  the  gueueing  discipline  to  be  assigned 
to  the  servers.  Jobs  are  always  served  in  a  first  come  first 
served  basis.  This  may  not  be  a  good  approximation  for  seme 
computer  systems  in  which  other  gueueing  disciplines  are 
implemented  in  order  to  improve  performance.  In  the  new 
version  of  the  simulator  the  following  additional  gueueing 
disciplines  are  available  to  the  user,  and  can  be  assigned 
independently  to  any  servergroup. 
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Figure    2.2        Closed   Queueing    Network. 
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(5)  Short  Processing  Time  First  (SPTF)  .  Jobs 
are  served  according  to  the  service  demand.  The  smallest 
service  reguest  is  served  first. 

(6)  Weighted    Short   Processing   Time    First 
(W5PTF) .     Jobs   are  served   according   to   the 

demand   and  priority.   The  job   with   the  smallest   reguest 
priority  ratio  is  served  first. 

c.   Measures  of  Performance 

Performance  parameters  such  as  system  throughput 
and  average  number  of  jobs  in  the  system  are  not  produced  by 
the  original  simulator. 

The  system  throughput  is  defined  as  the  number 
of  jobs  processed  per  unit  of  time.  Analysis  of  the  impact 
of  CPU  service  disciplines,  level  of  programming  or  number 
of  processors  on  the  system  throughput  are  likely  to  be 
performed  in  the  development  and  design  of  computer  systems. 

The  mean  number  of  jobs  in  a  gueueing  system  is 
expressed  analytically  in  terms  of  probabilities  and  random 
variables  as  described  in  LAVENBERG  [Ref.  1],  For  gueueing 
models  the  mean  number  of  jobs  in  the  system  is  analytically 
descrit€d  by  equation  2.  1 

s 

E[n]=  1/s  j[nu]  du  (eqn  2.1) 

Computation  of  this  value  by   the  simulator  is  time  weighted 
through  the  simulation  run  as  described  in  Chapter  3. 

3 •   Improvement  of  R un  Flexibility 

a.   Alternative   Methods  to   Specify  Simulation   Run 
Duration 

One  characteristic  of  simulation  programs  is 
that  they  must   provide  the  timing  mechanism  for  the  system 
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being  simulated.  A  list  of  coming  events  is  generated  and 
ranked  according  to  time  of  occurrence.  The  simulator  tracks 
the  list  and  cycles  through  the  following  steps: 

-  select  the  event  with  the  next  time 

-  set  the  clock  to  this  time 

-  perform  action  according  to  the  type  of  occurrence 

Simulation  run  duration  can  be  specified  by 
several  methods.  The  easiest  approach  consists  of  specifying 
the  number  of  times  the  group  of  statements  which  perform 
the  steps  described  above  are  to  be  executed. 

Specification  of  the  number  of  jobs  tc  be 
processed  through  the  modeled  system  is  an  alternative 
approach  and  was  chosen  by  the  original  program  designers. 
This  may  not  be  a  good  solution  for  closed  networks  where 
the  number  of  jobs  to  be  processed  is  not  clearly  defined. 
Another  disadvantage  of  this  approach  consists  of  the 
statistical  bias  introduced  by  the  shut-down  transition 
phase,  when  jobs  are  leaving  and  none  are  entering  the 
system.  Server  utilizations,  queue  lengths  and  response  time 
measurements  drop  in  that  phase,  affecting  the  final 
measurements  as  short  simulations  are  being  executed. 

The  most  usual  method  used  to  specify  run 
duration  consists  of  defining  the  total  time  of  the 
simulation  run.  One  advantage  of  this  approach  is  to 
facilitate  simulator  validation,  by  allowing  comparisons 
between  simulation  results  and  system  accounting  data 
gathered  for  the  same  period  of  time. 

The  new  version  of  CPMT  program  provides  the 
options:  number  of  jots,  number  of  events,  or  simulated  time 
as  specification  of  the  simulation  run  duration  for  open 
networks,  and  the  last  two  alternatives  for  closed  gueueing 
networks. 
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b.  Rerunning  a  Simulation 

After  producing  the  results  of  a  single 
simulation  run  the  new  version  of  CPMT  will  ask  whether  the 
user  wishes  to  run  the  simulation  again.  If  an  affirmative 
response  is  entered,  user  will  be  allowed  to  enter  new 
values  for  the  simulation  run  specifications  and  rerun  the 
model  with  no  need  to  return  to  the  MASTER  MENU. 

c.  Specification  of  Period  of  Time  for  Statistics 

Statistical  bias  introduced  by  simulation 
execution  start-up  transition  (jobs  are  entering  and  none 
are  leaving)  and  shut-down  transition  (jobs  are  leaving  and 
none  are  entering)  is  significant  when  short  simulation  runs 
are  executed.  A  statistic  oriented  feature  was  implemented 
in  the  new  CPMT  version  to  reduce  or  eliminate  such  effects 
by  providing  a  special  option  to  the  user  to  specify  limits 
on  the  interval  of  time  for  gathering  statistics. 

4.   Enhancement  of  User  Friendliness 

Simulator  user  interface  is  a  concern  of  simulation 
program  designers.  If  it  is  difficult  to  interact  with  a 
program,  the  users  will  be  less  likely  to  use  it.  User 
friendliness  had  been  implemented  in  the  original  simulator, 
and  modifications  and  additions  were  accomplished  to  further 
improve  user  program  interaction. 

a.   Display  cf  Model  Specifications 

A  new  option  was  included  in  the  MAIN  MENU  to 
display  a  specified  data  base  record  for  a  given  simulation 
model,  making  possible  on-line  validation  of  input  model 
specifications. 
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t.   Printing  cf  Specifications  for  a  Single  Model 

An  additional  option  to  print  the  data  rase  for 
a  single  model  was  implemented  to  improve  efficiency  and 
flexibility  in  accessing  data  base  information. 

c.  Updating  of  Model  Specifications 

Different  options  are  now  provided  to  handle 
user  reguests  depending  on  whether  there  is  already  an  user 
simulation  model  or  not.  If  a  simulation  model  already 
exists  in  the  data  case,  the  access  to  the  UPDATE  MENU  is 
given  from  the  MASTEB  MENU.  Otherwise,  the  option  to  enter 
the  new  simulation  model  number  will  display  the  model 
numbers  already  existing  in  data  base  to  prevent  collisions 
and  will  give  direct  access  to  the  UPDATE  MENU  as  a  new 
simulation  number  is  entered. 

d.  Copy  and  Eeletion  of  Simulation  Models 

Options  to  copy  and  delete  simulation  models 
were  moved  from  the  UPDATE  MENU  to  the  MASTER  MENU.  Ihe 
scope  of  the  main  options  in  the  new  version  is  defined  at 
the  simulation  model  level.  Updating  of  data  base  records  is 
accomplished  by  procedures  called  from  the  UPDATE  MENU 
rather  than  the  MASTEE  MENU. 

e.  Changing  of  Model  Specifications 

Modification  of  modeled  system  specifications  is 
likely  to  be  necessary  when  using  a  computer  system 
simulator.  No  option  to  change  model  specifications  was 
implemented  in  the  original  CPMT  simulation  program.  In  the 
new  version,  options  to  change  job  type  records,  routing 
records  and  servergroup  records  are  available  to  the  user, 
as  is  accessing  selected  items  within  records (  e.g.  job 
priority  within  a  job  type  record) .   Contents  of  the  records 
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before   and  after  changes  are   also  displayed   in  order  to 
facilitate  record  updating. 

f-   Facilities  for  Exception-handling 

A  goal  of  the  design  of  interactive  programs  is 
to  provide  facilities  for  exception-handling.  User  errors 
must  be  expected,  and  the  user  should  not  be  adversely 
affected  by  them. 

The  CPMT  program  control  is  driven  either  by 
user  specification  cf  menu  options  or  user  response  to 
prompt  messages.  The  original  CPMT  version  does  not  accept 
an  alphabetic  character  as  a  response  for  requested  options. 
In  such  case  the  program  will  abort  and  the  user  has  to 
restart  again.  In  the  new  version  this  will  be  interpreted 
as  an  invalid  option,  and  the  menu  will  be  displayed  again. 

The  convention  of  requiring  the  uppercase  'Y* 
for  a  'yes*  response  was  also  eliminated  for  the  revised 
program.  Both  upper  and  lower  case  of  the  lettee  are  assumed 
to  be  the  affirmative  response. 

Some  input  validation  is  performed  by  the 
original  program,  to  insure  that  input  values  are  within 
bounds  set  by  either  program  specification  (e.g.  menu 
options)  or  simulation  specification  (e.g.  mean  service 
time) .  Additional  input  validation  is  accomplished  by  the 
new  version  to  prevent  abnormal  program  termination. 

g.   Printing  cf  Specifications 

Distribution  types  and  gueueing  disciplines  are 
printed  on  the  screen  and  written  to  output  files  as 
meaningful  data  rather  than  numerical  values,  to  improve 
readability  of  program  output. 
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D.  BEVIEW  OF  PKOGRAH  DESIGN  AND  IMPLEMENTATION 

For  design  and  implementation  of  changes,  a  schedule  was 
established  according  to   the   following   priority  basis: 

-  Simulator    modeling  capability 

-  program  efficiency 

-  Simulation    run    flexibility 

-  Program  user  friendliness 

The  baseline  for  design  solutions  was  to  minimize  the 
impact  of  changes  en  the  program  modularity  and  data 
structures.  The  algorithms  and  implementation  considerations 
are  described  in  Chapter  3. 

E.  TESTING 

Program  testing  was  performed  throughout  the  change 
implementation.  A  few  errors  were  found  in  the  original 
program  and  fixed  during  testing  activity.  Verification  of 
program  correctness  under  new  processing  efficiency 
requirements  was  performed  by  comparison  of  the  execution  of 
the  new  program  with  the  execution  of  the  original  program, 
followed  by  analysis  of  results.  The  quality  of  the  program 
as  a  simulation  tool  is  discussed  in  Chapters  5  and  6. 

F.  UPDATING   OF    DOCUMENTATION 

Technical  and  user  documentation  was  updated  to  reflect 
changes  in  program  code  and  simulator  operation.  In  addition 
to  rewriting  the  comments  in  the  listing  file,  a  change  log 
was  created  to  facilitate  further  program  maintenance.  The 
change  log  and  the  new  version  of  the  CPMT  user's  manual  are 
presented   in   the   next  two  chapters   of   this   thesis. 
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III.  CHANGE  LOG 

In  order  to  provide  information  necessary  to  understand 
the  current  modifications  and  trace  the  evolution  of  the 
CPHT  program  from  the  initial  configuration,  a  change  log 
was  created.  This  chapter  summarizes  and  presents  the 
contents  of  the  log.  Entries  to  the  log  include  the 
following  information,  if  applicable  : 

-  Change   number 

-  Type  of  maintenance    (Corrective, adaptive  or    perfective) 

-  lype   of   requirement 

-  Brief   description  of   requirement  or   anomaly 

-  Change   design 

-  Changes   in    records   and    data  items 

-  Files   affected 

-  Modules  affected 

-  Procedure   and/or   Functions   eliminated  or  changed 

-  New   procedures    and/or   Functions 

-  Explanation 

-  Impact  on  the  prcgram  modularity, clarity  etc. 

Changes  implemented  as  a  result  of  this  thesis  effort 
are  described  in  the  next  sections,  grouped  by  typ€  of 
maintenance  and  classification  of  requirements  as  described 
in  Chapter  2.  Change  numbers  were  sequentially  assigned  for 
easier  reference.   Statistics  about  the  type  and   volume  of 
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maintenance  are   presented   in  the   last  section   of   this 
chapter. 

A.   PERFECTIVE  CHANGES 

1 .   Seduction  of  Kemory  Requirement s 

a.   CHANGE  #1 

t.   Change  Design 

Dynamic  creation  and  allocation  of  job  and  event 
records  as  a  simulation  is  being  processed. 

c.  Change  Dictionary 

Items  NEXT_SERV  and  COMPLETE  were  created  for 
the  JOB  TYPE  RECORD,  to  identify  the  servergroup  at  which 
the  next  processing  event  will  take  place,  and  detect  the 
job  completion;  the  item  FIRST_JOB_PART  of  the  same  record 
was  eliminated;  items  NEXT_JOB_PART  and  SCHEDULED  were 
eliminated  from  the  EVENT  RECORD. 

d.  Files  Affected 

CEKT. PAS 
CJS.PAS 

EXT. PAS 

e.  Modules  Affected 

CREATE  JOB  STREAM 
EXECUTE  AND  TABULATE 

f.  Procedure  Eliminated 

CREATE  JOB  STREAM 
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g.      Procedures  Changed 


CREATE_JOB 

EXICUTE_AND_T ABU LATE 

DEPART_FROM_SG 

JCE_ARRIVAL 

JOB_COMPLETED 

A  REIVE    AT    SC- 


li.   New  Procedures 

FIKD_JOB_TYPE 
CREATE_INITIAL_JOBS 
CREATE_NEfl_EVENT 
EXICUTE 

i.      Explanation 

There  is  no  job  stream  in  the  new  design,  thus 
the  procedure  CREATE_JOB_STREAM  was  eliminated.  The  name  of 
the  respective  module  was  not  modified  for  easier  reference. 
The  new  input  for  the  EXECOTE_AND_TABULATE  module  is  the 
linked  list  of  job  records  created  by  the  new  procedure 
CREATE_INITIAL_JOBS,  and  consists  of  one  job  of  each  job 
type  of  the  simulated  model.  Each  job  record  is  created  by 
the      modified      procedure      CREATE_JOB,  and      has      only      one 

associated  EVENT  record  which  stores  the  information 
required  for  the  first  event  of  that  job.  Creation  of  events 
during  a  simulation  run  is  requested  from  the  procedure 
EXECUTE_AND_TABDLATE    as   a    job    departs  from   a    servergroup. 

Creation  cf  jobs  during  a  simulation  run  depends 
on  the  type  of  network  being  simulated.  For  the  original 
program  capability,  open  networks,  the  process  is  as 
follows:  as  a  job  arrives  to  the  servergroup  0  (dummy 
server), the  procedure  JOB_AEEIVAL  invokes  first  the  new 
procedure   FIND_JOB_T'YEE   in    order    to      access    in   the    data   base 
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the  JCB  TYPE  record  with  the  same  job  type,  and  then  calls 
the  procedure  CREATE_JOB  to  create  a  new  job.  Allocation  of 
job  and  event  records  for  the  new  job  depends  on  whether 
there  are  records  available  or  not.  As  a  job  completes,  the 
job  type  record  is  referenced  by  a  pointer,  and  a  flag  is 
set  to  notify  the  procedure  CEEATE_JOB  that  there  is  no  need 
to  allocate  new  records.  In  this  case,  the  CREATE_JOB 
procedure  updates  the  job  and  event  records  for  the  new  job. 
Otherwise,  new  job  and  event  records  will  be  allocated.  The 
arrival  time  of  the  new  job  is  computed  as  the  arrival  time 
of  the  arrived  job  plus  the  interarrival  time  calculated  in 
the  procedure  CREATE_JOB.  The  job  record  is  attached  to  the 
arrival  gueue  for  the  servergroup  0  and  becomes  ready  to  be 
processed.  A  counter  is  incremented  to  keep  track  of  the 
number   of   jobs    processed. 

As  referenced  above,  there  is  a  single  event 
record  associated  with  each  job  record.  That  record  is 
updated  by  the  new  procedure  CREATE_NEW_EVENT  which  is 
called  by  the  procedure  DEPART_FROM_SG.  As  a  job  departs 
from  a  servergroup,  the  number  of  the  next  servergroup  to 
which  the  job  is  routed  is  checked.  If  that  servergroup  is 
not  the  exit  servergroup  (SG10)  a  new  event  is  created  for 
that    job. 

A  new  procedure  EXECUTE  was  created  within  the 
procedure  EXECUTE_fiND_TABULATE        for  easier  program 

readability.  This  procedure  handles  the  processing  loop  of 
job  departures  and  arrivals  and  calls  the  procedures 
DEPART_FROM_SG    and    ARRIVE_AT_SG. 

j.   Impact  on  the  Program  Modularity 

Program  modularity  was  affected  by  this  change. 
Procedures  CREATE_JCE,  CREATE_NEWEVENT  and  FIND_JOB_TYPE 
from  the  module  CREATE  JOB  STREAM  are  called  by  procedures 
from    the   EXECUTE    AND    TABULATE    module. 
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2.   Reduction  of  Processing  Time  to  Produce  Statistics 

a.  CHANGE  #2 

b.  Change  Design 

There  is  no  longer  a  need  to  traverse  a  linked 
list  of  job  records  for  gathering  statistics;  information  is 
collected  as  jobs  complete.  Standard  deviation  computations 
in  the  new  design  are  calculated  by  a  different  algorithm 
that  is  described  in  the  change  explanation. 

c.  File  Affected 

EXT. PAS 

d.  Module    Affected 

EXECUTE    AND    TABULATE 

e.  Procedures   Eliminated 

STD_DEV 
STI_DEV_JOB_TYPES 

f.  Procedures  Changed 

JCE_COMPLETED 

STATS_FOR_JCBS 

STATS_FOR_JOB_TYPES 

g.  New    Procedure 

IMITIALIZE_STATS 

h.      Explanation 

A  new  procedure  INITIALIZE_STATS  was  created  to 
initialize  the  statistical  counters  and  accumulator 
variables. 
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As  each  job  completes,  the  values  of  the 
statistical  counters  and  accumulator  variables  are  updated; 
as  the  processing  of  jobs  is  completed,  procedures 
STATS_FOR_JOBS  and  STATS_FOR_JOB_TYPES  compute  and  print 
statistics   for   all   the   jobs   and   for    each    job   type. 

For  computation  of  standard  deviations  let  T  be 
defined    ty    equation    3.1    : 

N 
T    «£j    X—   MEAN    )2  (eqn    3.1) 

Using   binomial   theorem  in   equation    3.1    ,      T   can    be    expressed 
as: 

N  N 

T    =5Zx.2   -    2*MEAN*£j(L  +    N*MEAN2  (eqn    3.2) 

A/ 

MEAN    =Ylxy    N  (e9n    3'3) 

i-\ 

N 
Substituting  ^ X:  from  equation      3.3    and   simplifying   eguation 

3.2    ,    T   can    be   defined   as: 

N 
T    =7~X2    -    N*MEAN2  (eqn    3.4) 

N 

VARIANCE    =XI(X;~    KEAN)  2    /    N  (eqn    3.5) 

1,=./ 

STANEARD    DEVIATION    =      \JMEAN  (eqn    3.6) 

Using   equations    3.4    ,      3.5    and    3.6    ,       STANDARD    DEVIATION   can 
be   expressed   by    the    following   equation    : 


\/        * 

STANEARD    DEV    =        V    (  5T  x2    "    N*MEAN2)/N  (eqn    3.7) 


\-\ 


Eased   on  eqs  3.3,      3.4   and        3.7    the   following   algorithm   was 
implemented: 
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At     the   ith      job   completion        compute   the 

square  of      the   current  variable  X      and   update 
the   statistical  accumulator  5>~  X? 


As  the      processing  of      jobs    is      finished 

(Nth    job  completion) ,      compute     the    values  of 
the    MEAN,    T    and    STANDARD    DEVIATION. 

B.       ADAPTIVE   CHAIGES 

1 .      Capability   for  Closed  Oueueinq   Network  Modeling 

a.      CHANGE    #3 

h.      Change   Design 

Dynamic  creation  of  jobs  is  accomplished  by  two 
distinct  methods  whether  the  model  being  simulated  is  an 
open  or  closed  network.  For  open  networks,  as  described  in 
change  #1,  the  linked  list  of  jobs  created  by  the  procedure 
CREATE_INITIA1_J0BS  consists  of  one  job  for  each  job  type. 
If  a  closed  network  is  being  simulated  the  number  of  jobs 
for  each  type  created  by  the  CREATE_INITIAL_JOBS  procedure 
depends  on  the  model  specification  and  is  detemined  by  the 
level  of  programming  for  each  job  type.  Furthermore,  for 
closed  network  modeling,  a  job  completion  will  force  the 
arrival   of   an   identical   job    into   the   system. 

c.      Files    Affected 

CJ£.PAS 
OIKOD.PAS 
EXT. PAS 

CERT. PAS 
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Modules    Affected 


CREATE   JOB    STREAM 

UPDATE 

EXECUTE    AND    TABULATE 

MAIN    DRIVER 

e.  Procedures   Changed 

ADD_JOB_TYPE 

EXICUTE_AND_TABULATE 

DEPART_FROM_SG 

JCE_ARRIVAL 

J0B_COMPLETED 

f.  New    Procedure 

CEECK_NET_T?PE 

g.  Explanation 

The  program  processes  jobs  according  tc  the 
simulation  number  assigned  to  the  modeled  system.  A  new 
procedure  CHECK_NET_TYPE  returns  the  value  of  a  boolean 
variable  determined  by  the  simulation  model  number  used  as 
input.  Simulation  models  1  through  49  are  assigned  to  open 
networks   and  50    through   100    to  closed   network  modeling. 

These  ranges  can  be  easily  changed  by  modifying 
the    bcund  assigned   in  the  procedure   CHECK_NET_TYPE 

For  closed  networks  the  arrival  time  assigned  to 
job  records  is  not  dependent  on  the  user  specifications,  but 
rather  determined  by  the  procedure  which  drives  the  creation 
of  the  new  job.  lor  jobs  created  by  the  procedure 
CREATE_INITIAL_JOBS  the  arrival  time  is  one  l  ,  otherwise 
(jobs  created      by   the     procedure  JOB_COMPLETE)         the  arrival 


1The  deterministic  and  short  interarrival  time  was 
chosen  by  the  program  designer  to  reduce  the  elapsed  time  to 
initialize   the   closed  network 
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time  for  the  new  jot  will  be  the  time  the  completed  job 
leaves  the  system.  A  flag  is  set  at  each  job  completion  to 
define  the  instant  a  new  job  has  to  be  scheduled.  The 
procedure  DEPART_FROM_SG  will  force  a  new  event  that  will  be 
a  departure  from   the    servergroup    0. 

2.      Capability    for   Alternative  Queueinq   Disciplines 

a.       CHANGE    #4 

t.   Change  Design 

The  gueueing  discipline  to  be  observed  at  a 
given  servergroup  is  specified  by  the  user  as  he  is  adding 
routing  records  to  a  job  type.  Whenever  a  job  arrives  to  a 
servergroup  that  has  a  waiting  queue,  it  is  inserted 
according  to  the  gueueing  discipline  specified  for  that 
servergrcup. 

c.  Change   Dictionary 

New  items  REC_DISC  and  Q_DISC  were  included 
respectively  in  the  EfiTA  BASE  and  SERVER  records  to  identify 
the  gueueing  discipline   assigned    to   the   servergroup. 

d.  Files  Affected 

RFCFILE.DAT 
EXT. PAS 
CIBT.PAS 

e.  Modules   Affected 

UEEATE 

EXECUTE    AND    TABULATE 
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f.      Procedures   Changed 


ADC_ROUTING_RECORD 

IC_EDIT 

PEINT_R 

B01LD_LL_FRCM_DB 

PROCESS_RODTING_DATA 

EXECUTE_AND_TABULATE 

CREATE_SERVER_GROUPS 

AERIVE_AT_SG 

DEPART_FROH_SG 

INSERT_IN_SG_Q 

AT1ACH    JOB    TO    SERVER 


g.      New    Procedures 

SG_Q_INSERT_FRONT 
SG_Q_INSERT_PRIORITY 
S  G_Q_INS  ERT_PROC_TIME 
SG_Q_INSERT_HEIGHT 
SG_Q_INSERT_RANDOM 

h.      Explanation 

The        gueueing        discipline  assigned        to        a 

servergroup  is  stored  in  the  database  as  the  user  adds 
routing  records  to  a  job  type  record.  As  the  linked  list  for 
routing  jobs  is  created  (procedure  CREATE_ROUTING_RECORD)  , 
the  values  of  the  gueueing  disciplines  are  stored  in  a  one 
dimensional  array.  The  procedure  CREATE_SERVER_GROOPS  reads 
from  that  array  the  discipline  that  is  to  be  assigned  to 
each  servergroup,  and  stores  it  into  the  respective 
servergroup   record. 

The  selection  of  procedures  for  implementation 
of  the  scheduling  algorithm  to  be  observed  at  a  servergroup 
is   performed   by   the    procedure   INSERT_IN_SG. 
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The  procedures  to  implement  the  Last  Come  First 
Served  (LCFS) ,  Nonpreemptive  Priority  (NP)  ,  Lowest 
Processing  Time  First  (LPTF) ,  and  Lowest  Weighted  Processing 
Time  First  (LWPTF)  algorithms  are  self  explanatory. 

Simulation  of  random  service  is  accomplished  by 
random  insertion  of  jobs  in  the  waiting  queue;  the  position 
in  which  a  job  is  inserted  is  computed  from  the  function 
GENERATE_VALUE ,  using  the  number  of  queued  jobs  that  is 
stored  in  the  servergroup  record. 

The  PROCESSOR  SHARED  implementation  is  based  on 
the  algorithm  described  in  SADER  and  CHANDY  [Ref.  4  :p-200]# 
and  it  is  distributed  across  the  procedures 
SG_Q_INSEET_PROC_TIME,  ATT ACH_JOB_TO_SERVER ,  and 
INSER1_IN_SG_Q.  The  job  with  the  smallest  processing  time 
must  be  the  first  to  leave  the  queue  and  so, the  smallest 
processing  time  first  algorithm  is  used  for  insertion  into 
the  waiting  queue.  Computation  of  the  service  time  depends 
on  the  number  of  jobs  waiting  to  be  served  and  is  equal  to 
that  number  times  the  request  time  of  the  current  job  being 
served.  When  the  job  completes  service,  that  amount  of  time 
is  subtracted  from  the  request  of  each  job  in  the  queue,  if 
any,  to  obtain  the  job  remaining  requests. 

i.   Impact  on  the  Program  Modularity 

The  procedure  INSEBT_IN_SG_Q  in  the  EXECUTE  AND 
TABULATE  module  calls  the  function  GENERATE_RANDOM_VALUE 
outside  the  module,  to  generate  a  random  position  for 
insertion  into  the  waiting  queue. 

3.   Computation  of  the  Mean  Number  of  Jobs  in  the  System 

a.   CHANGE  #5 
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h.   Change  Design 

The  algorithm  for  a  time  weighted  computation  of 
the  number  of  jobs  in  the  system  is  described  in  the  change 
explanation. 

c.  File  Affected 

EXT. PAS 

d.  Module   Affected 

EXECUTE    AND    TABULATE 

e.  Procedures  Changed 

JCE_ARRIVA1 
JCB_COMPLETED 
STATS_FOR_JCBS 
S1ATS_F0R_J0B_TYPES 

f.  Explanation 

As  illustrated  in  Figure  3. 1  the  value  of  the 
mean  number  of  jobs  depends  on  the  time  accumulated  value  of 
the  area  under  the  ccrve,  An .  The  value  of  Anat  the  instant 
t^  is  computed  from  equation  3.8  where  t,-  is  the  time  of  a 
job  arrival  or  departure,  and  N^_,  is  the  number  of  jots  in 
the   system   at   time   t;_,. 

The  algorithm  used  for  computation  of  the  mean 
number  of  jobs  in  the  system  was  implemented  for  all  jobs 
and  for  each  individual  job  type.  Computation  of  the  value 
of  kn  at  a  given  tine  is  performed  either  by  the  procedure 
JOB_AERIVAL  or  JCB_CCPPLETED  depending  on  if  the  event  is  an 
arrival  to  the  system  or  a  jcb  completion.  The  number  of 
jobs  in  the  system  at  times  tj,  and  tjH  are  stored  in  the  array 
TOTAL_JOES_SYS,  and  the  values  of  tj  and  t^,  are  stored  in  the 
array  INTEREVENT.         As  the   value     of   A;    is      calculated,      the 
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Figure  3. 1    Bean  Nuaber  of  Jobs  in  the  System 


=  H^i  -*i-i  )*N 


(egn  3.8) 


t  -  i 


values  of  N;_,  and  tj_,  ,  which  are  no  longer  required,  are 
replaced  by  the  values  N;  and  t  i  to  prepare  for  the  next 
computation.  The  example  shown  in  Figure  3.2  illustrates 
the  application  of  the  algorithm. 

The  last  step,  which  computes  the  mean  value, 
consists  of  dividing  the  accumulated  area  by  the  simulation 
time.  This  step  is  performed  by  the  procedures 
STATS  FOR  JOBS  and  STATS  FOR  JCB  TYPES. 
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1)      Initial  data 


t      =    50                                           INTEREVENT(O)  =  50 

INTEREVENT(I)  =  ** 

N      =    4                                                TOTAL    JOBS    SYS(O)  =  4 

TOTAL~JOBS~SYS (1)  =  ** 
AREA    =    12                                                   ~ 


2)    At   time   55    occurs   a    job   departure 

:nt(0) 
:nt(1) 

)BS    SY 


t         =       55  INTEREVENT(O)  =      50 

INTEREVENT(I)  =       55 

N         =         3  TOTAL    JOBS    SYS(O)    =         4 


M  = 


TOTAL~JOBS~SYS(1 

3)    Computation    of   the   new    AREA   at    time   55 
AREA   =    AREA    ♦ 

TOTAL_JOBS_SYS  (0)  *  (INTEREVENT  ( 1)  -INTERE7ENT  (0)  ) 
AREA  =    12    ♦    4  *     (    55   -    50   ) 
AREA  =       32 


4)  Preparation  for  the  next  computation 

rENT(0) 
rENT(1) 
rOBS    SY 


INTEREVENT(O)  =         55 

INTEREVENT(I)  =  ** 

TOTAL    JOBS    SYS (0)     =  3 


TOTAL~JOBS"SYS(1)     =         ** 


m  = 


Figure  3.2   Ccaputation  of  the  Accumulated  Area 

^  •   Interval  for  Gathering  Statistics 

a.  CHANGE  #6 

b.  Change  Design 

Updating  cf  the  job  and  servergroup  records  as  a 
simulation  is  being  processed  is  performed  over  a  period  of 
time  specified  by  the  user. 
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Files  Affected 

C£ET.PAS 
EXT. PAS 
MESSAGES.  DAT 

Modules    Affected 


MAIN    DRIVER 

EXECUTE    AND    TABULATE 


e.  Procedures   Changed 

STATS_FOR_J0BS 

STATS_FOR_JOE_TYPES 

STATS_FOR_SERVERG ROUPS 

JCE_ARRIVAI 

JOE_IN_SG_Q 

NC_JOB_IN_SG_Q 

JCB_COMPLETED 

ATTACH_JOB_TO_SERVER 

ATTACH_FIRST_IN_Q 

INSERT_IN_SG_Q 

f.  Explanation 

Gathering  of  information  from  job  and 
servergrcup  records  to  produce  statistics  is  performed 
depending  on  whether  a  flag  is  set  or  not.  The  flag  is 
implemented  by  the  toolean  variable  STATS  and  its  value 
depends  on  the  simulation  run  specifications  selected  by  the 
user,  as  shown  in  the  diagram  of  Figure  3. 3  . 

As  the  simulator  timing  mechanism  is  driven  by 
events,  the  specification  of  the  interval  for  gathering 
statistics  introduces  the  need  of  a  correction  in  the 
computation  of  the  number  of  jobs  in  the  system,  as 
illustrated  in  Figure  3.4. 
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Input 
start  time 
stop  time 


no 


*  STATS  =  TRUE 


-L3. 


STATS  =  FALS 


yes 


Figure  3.3   Value  of  the  Statistical  Flag 

As  statistics  start  up  and  shut  down,  the  areas 
A1  and  A2  are  calculated  at  the  ocurrence  of  events  t,  and  t, 
,  using  equations  3.9  and  3.10  where  Na  and  Nc  are  the 
number  of  jobs  in  the  system  at  times  ta  and  tc.  Computation 
of  areas  A1  and  A2  and  respective  summation  to  the  total 
accumulated  area  A  are  performed  either  by  the  procedure 
J03_AREIvAL  or  JOB_CCMPLETED  depending  on  whether  the  events 
t     and   t      are    job  arrivals   to   the  system   or    job    completions. 
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jobs 


(IN.) 


I  I 


A 


tu  iturt 


4» 


t.      -5to|5     tx       fi'Me 


Figure    3.4        Start   and    Stop    Areas 


A1    =     {tb   -    start_stats)    *    Na  (e<jn    3.9) 

A2    =    (stop_stats   -    tc    )    *    Nc  (egn    3. 10) 

5.      Commutation    cf    the    System   Throughout. 

a.  CHANGE  #7 

b.  Change  Design 

Accounting  of  the  number  of  job  completions  for 
all  jobs  and  by  individual  job  type;  division  of  those 
numbers  by  the  elapsed  time  to  determine  the  rate  of 
throughput. 


42 


c-   File  Affected 
EXT. PAS 

d.  Module    Affected 

EXECUTE    AND    TABULATE 

e.  Procedures   Changed 

JOE_COMPLETED 

STATS_FOR_JOBS 

STATS_FOR_JOB_TYPES 

f.  Explanation 

Statistical  counters        in  the  procedure 

J03_CCMPIETED  keep  accumulating  the  number  of  job 
completions  as  the  simulation  is  being  processed.  The 
procedures  STAT_FOR_JCBS  and  STATS_FOR_JOB_TYPES  compute  the 
throughput      values,  by      dividing      the      total        number     of 

completions  by   the    sinulated   time. 

6.      Alternative    Specification  of   Run    Duration 

a.       CHANGE    #8 

fc.   Change  Design 

When  a  simulation  run  is  to  be  processed,  the 
user  specifies  the  option  for  run  duration.  The  option  is 
either  tc  end  the  simulation  after  a  specified  number  of 
events  or  after  a  specified  simulation  time.  Different 
conditions  are  set  for  controlling  the  number  of  iterations 
of  the  processing  loop  depending  on  the  choice. 

c.   File  Affected 

EXT. PAS 
CICT. PAS 
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d.      Modules    Affected 


EXECUTE    AND    TABULATE 
MAIN    DRIVER 


e.  Procedures  Changed 

EXECUTE_AND_TABULATE 
JOE_ARRIVAL 

f.  Explanation 

In  the  original  program  the  run  duration  is 
always  defined  by  the  number  of  jobs  to  be  processed,  and 
the  execution  of  the  main  processing  loop  in  the  procedure 
EXECUTE_AND_TABULATE  terminates  when  there  are  no  pending 
events  to  be  processed  in  the  servergroups.  The  alternative 
conditions  created  for  controlling  the  processing  loop  are 
enabled  fcy  the  user  specification  of  either  the  number  of 
events  or  simulation  time.  In  such  cases  the  variables  to  be 
checked  by  the  processing  loop  will  be  either  a  counter 
placed  inside  the  loop  or  the  clock.  The  case  structures  on 
the  main  driver  select  the  control  of  the  processing  loop 
according  to  the  type  of  network  and  user  specification  of 
the  run  duration. 

If  the  run  duration  is  specified  by  simulated 
time,  and  no  interval  for  statistics  was  defined,  a 
correction  has  to  be  done  for  computation  of  the  average 
number  of  jobs  in  the  system.  As  the  simulator  timing 
mechanism  is  actually  controlled  by  the  occurrence  of 
events,  the  execution  of  the  processing  loop  terminates  at 
the  event  which  occurs  closest  to  the  specified  simulated 
time,  see  Figure  3.5  .  As  the  computation  of  the  mean 
number  of  jobs  is  time  weighted,  as  explained  in  Change  #5, 
the  last  area  to  be  accumulated  in  this  case  is  calculated 
from  equation  3.11  where  t£  is  the  last  event  processed 
before  the  simulation  time  is  over. 


4U 


A    =    (siiulated_ti me  -    tg ) *    Nj 


(eqn    3.  11) 


N 


evtnt 


end  ot 
■time 


Figure   3.5        Correction   of   the   Accumulated    Area 


This        computation  is        performed        by  the 

STATS_FCE_J03S         for      all         jots         and         by      the 
STATS_F0B_JOB_TYPES    fcr   each    jcb    type. 

7-      Capability   for   Rerunning   a   Simulation 

a.   CHANGE  #9 


procedure 
procedure 


t.   Change  Design 

The   program   cycles   through 
execution  code  under  user  control. 

c.   File  affected 

CFMT.PAS 


the      simulation 
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d.  Module   affected 

Main  Driver 

e.  Explanation 

When  a  mcdel  specification  is  correct,  it  can  be 
repeatedly  executed.  The  condition  for  loop  termination  is 
set  by  the  user  response  to  a  prompt  message. 

8-   Display  of  Model  Specifications 

a.   CHANGE  #10 

t.      Change   Design 

An  additional  option  was  included  in  the  MASTER 
MENU  and  a  new  procedure  was  created  for  printing  single 
data    base  records   on   the   screen. 

c.  Files  affected 

UIKOD. PAS 
CPMT.PAS 
MESSAGES.  DAT 

d.  Modules    affected 

UPDATE 
MAIN    DRIVER 

e.  New   procedure 

DI£PLAY_MODEL 

f.  Explanation 

The  new  procedure  DISPLAY_MODEL  was  placed 
within  the  UPDATE  module  and  is  called  from  the  case 
construct  implemented  in  the  main  driver.  It  first  attempts 
to      locate   the      simulation   model      in      the   data      base   by      the 
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record  key  computed  from  the  entered  simulation  model 
number.  If  the  key  is  not  found  an  error  message  is 
presented,  otherwise  the  record  type  and  number  will  be 
prompted  for.  In  this  case  the  procedure  attempts  to  locate 
the  selected  record  in  the  data  base;  if  the  record  key  is 
found  the  record  contents  are  displayed,  otherwise  an  error 
message  will  be  produced.  The  procedure  cycles  through  these 
steps    if  the  user   desires. 

9 .      Printing   of    Model  Specifications 

a.      CHANGE    #11 

t.   Change  Design 

An  additional  option  was  included  in  the  MASTER 
MEND  and  a  new  procedure  was  created  for  printing  all 
records  of  a  simulation  model  to  the  output  file. 

c.  Files   Affected 

UFMOD.PAS 
CEET.PAS 

MESSAGES.DAT 

d.  Modules    Affected 

UPDATE 
MAIN    DRIVER 

e.  New   Procedure 

PRINT_DATA_EASE_MODEL 

f.  Explanation 

The  new  procedure  PRINT_DATA_BASE_model  is 
called  from  the  Main  Eriver  and  first  attempts  to  locat€  the 
simulation  model  by  the  key  computed  from  the  entered 
simulation   model   number.      If  the   record      key    is    not    found  an 
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error  message  is   displayed,   otherwise  all  the   records  for 
that  simulation  model  will  be  printed  to  the  file  OUTFILE. 

10.  Updating  of  Model  Specifications 

a.  .CHANGE  #12 

b.  Change  Design 

Updating  of  the  data  base  in  the  original 
program  design  is  processed  by  first  selecting  the  option 
from  the  MASTER  MEND  to  update  the  data  base,  and  then 
entering  the  simulation  model  number.  If  an  already  existing 
simulation  model  number  is  entered  by  the  user,  the  program 
produces  an  error  message,  otherwise  the  UPDATE  MENU  is 
displayed. 

The  new  version  has  a  special  option  in  the 
MASTEE  MENU  to  enter  a  new  simulation  model  number,  which 
will  display  a  list  of  the  simulation  numbers  already 
existing  in  the  data  base;  as  the  user  enters  a  new 
simulation  model  numter  the  UPDATE  MENU  is  automatically 
displayed  and  the  program  becomes  ready  for  record  updating. 

The  update  option  in  the  MASTEE  MENU  is  to  be 
selected  if  a  user  already  has  simulation  models  in  the  data 
base. 

c.  Files  Affected 

UPKOD.PAS 

CIMT.PAS 
MESSAGES.DAT 

d.  Modules   Affected 

UEEATE 
MAIN    DRIVER 
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e-      Procedures  Changed 

ENTER_SIM_NUM 
UPDATE_MENU 

f.  New    Procedure 

PRINT_SIM_NOM 

g.  Explanation 

The  modified  procedure  ENTEB_SIM_NUM  is  called 
from  the  MAIN  DRIVER  rather  than  from  the  procedure 
UPDATE_MENU,  if  the  options  "enter  new  simulation  number"  or 
"updating  of  model  specifications"  are  selected  by  the  user. 
If  the  first  option  is  chosen,  the  new  procedure 
PRINT_SIM_NUM  will  be  called  to  search  for  the  existing 
models  and  display  their  numbers  on  the  screen.  If  the  data 
base  is  empty  an  appropriate  message  will  be  displayed.  In 
both  options,  but  for  different  reasons,  the  procedure 
ENTEE_SIM_NUM  checks  for  a  repeating  key  before  giving 
access  to  the  UPDATE  MEND.  Appropriate  messages  will  be 
displayed  for  the  case  of  entering  a  repeated  simulation 
number  as  a  new  number,  or  trying  to  update  a  nonexisting 
simulation   model. 

11.    Deletion   and   Cop_£  of    Simulation    Model 

a.  CHANGE  #13 

b.  Change  Design 

In  the  nev  design,  as  described  in  Chapter  2, 
the  scope  of  the  main  options  is  defined  at  the  simulation 
model  level  and  so  copy  and  deletion  of  simulation  models 
are  ortions  from  the  MASTER  MENO  rather  than  from  the  UPDATE 
MENU. 
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c.  Files   Affected 

UFMOD.PAS 
CJKT- PAS 
MESSAGES.DAT 

d.  Modules    Affected 

UPDATE 

MAIN    DRIVER 

e.  Procedure  Changed 

nrrATE_MENo 

f.  Explanation 

The  procedures  DEL_SIK_MODEL  and  COPY_SIM_MODEL  for  deletion 
and  copy  of  model  records  from  the  data  base  were  moved 
outside  of  the  procedure  UPDATE_MENU  and  are  called  from  the 
case    structure   implemented    in    the   main   driver. 

12.    Changing   of    the   Model    Sp_e ci f ica t io ns 

a.  CHANGE  #14 

b.  Change  Design 

Implementation   of      procedures   for      modifying   the 
contents  of   data   base  records. 

c.  File   Affected 

UEKOD.PAS 
MESSAGES-DAI 

d.  Module    Affected 

UPDATE 
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e.  Procedure  Changed 

OPEATE_MENO 

f.  New    Procedures 

CHANGE_JOB_TYPE_REC 
CEG_EO0TING_REC 
CEG_SERVER_BEC 
PRINT_REC 

g.  Explanation 

The  new  procedures  implemented  for  changing  of 
data  base  records  are  called  by  the  procedure  OPDATE_MENU  if 
the  respective  option  is  selected  by  the  user.  They  control 
the  sequence  of  events  required  to  compute  the  correct 
record  key,  locate  the  record,  obtain  new  data  and  perform 
changes  in  the  data  records.  All  of  the  procedures  call  the 
new  procedure  PRINT_EEC  to  display  the  contents  of  the 
records   before    and  after  changes. 

13.    Handling   of    Alphabetic   Characters 

a.       CHANGE    #15 

t.      Change   Design 

The      program      accepts    alphabetic     characters  as 

input    fcr      options   tc  displayed      menus.      The     characters  are 

converted      to      integers      before      selection      of      code      tc  be 
executed. 

c.      Files   Affected 

UPMOD.PAS 
CIKT.PAS 
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d.  Modules    Affected 

UEEATE 
MAIN    DRIVES 

e.  New    Function 

OF  HON 

f.  Explanation 

In  the  CPMT  program  design,  a  set  of  case 
structures  had  been  implemented  to  process  the  selection  of 
menu  options;  all  the  selection  variables  for  these  control 
structures  are  integers.  In  the  original  version  the  input 
value  which  represents  the  option  is  an  integer  and  is 
assigned  directly  to  the  selection  variable;  in  the  new 
version  the  input  value  is  read  as  a  character  and  converted 
to  integer  by  the  function  OPTION,  and  then  is  assigned  to 
the  selection  variable. 

11*-  Printing  of  Eistributions  and  Qeueing  Disciplines 

a.   CHANGE  #16 

t.   Change  Design 

In   order  to   provide   a   more  comprehensable 

output,    the    program   distribution   type  and    gueueing 

discipline  codes   are  translated  to  english  before  printing 
on  screen  and  output  file. 

c.  File  Affected 

OPMOD.PAS 

d.  Module  Affected 

UPDATE 
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e.  Procedure  Changed 

PEINT_R 

f.  New  Procedure 

CCNVERT_OPT_STR 

g.  Explanation 

Before  printing  either  on  screen  or  output  file 
the  job  type  and  routing  records,  and  for  the  data  items 
distribution  type  and  gueueing  discipline,  the  respective 
printing  procedures  call  the  nev  procedure  CON VERT_OPT_STR 
to   convert   integer   values   to   preassigned    string    values. 

C.       CCBBP.CTIVE    CHAIG1S 

1  -      Error   in   Deleting  a    Simulation   Model 

a.  CHANGE  #17 

b.  File  Affected 

UPMOD.PAS 

c.  Module    Affected 

UPDATE 

d.  Procedure  Changed 

DE1ETE_SIM_M0D 

e.  Explanation 

The  original  program  terminates  if  the  last 
simulation  model  in  the  data  base  is  deleted.  The  error  was 
located  in  the  procedure  CHECK_SIM_SPECS,  and  it  was  fixed 
by  adding  the  end  of  file  (EOF)  function,  as  a  condition  to 
be   checked   in   the  while  loop   implemented   to    delete    records. 


53 


2.      Error   as   Executing   a  Simulation 
a.      CHANGE    #18 
fc.      File   Affected 

CF.ECKSS.  PAS 

c.  Module   Affected 

CKECK    SIM    SPECS 

d.  Procedure  Changed 

CEECH_SIM_SPECS 

e.  Explanation 

The  original  program  terminates  if  it  attempts 
to  run  a  simulation  mcdel  with  no  records  stored  in  the  data 
Lase.  The  run  time  error  was  fixed  by  calling  the  procedure 
that  checks  errors  in  the  routing  record  specifications  only 
if  no  other  errors  were  found  in  the  head  or  job  type 
records  specification. 

3-   Incorrect  Handling  of  Multiseryers 

a.   CHANGE  #19 

t.      File  Affected 

EXT. PAS 

c.  Module   Affected 

EXECUTE  AND  TABULATE 

d.  Procedure  Changed 

FIND  NEXT  EVENT  TIME 
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e.      Explanation 

The  algorithm  to  find  the  next  event  for  a 
servergroup  did  not  work  properly  if  there  is  more  than  one 
server  specified  for  that  servergroup;  the  results  are 
incorrect  statistics  for  all  jobs  and  individual  job  type. 
The  error  was  located  in  the  procedure  FIND_NEXT_EVENT_TIME, 
and  it  was  fixed  by  adding  a  test  condition  to  be  checked  in 
the   loop   that   searches   for    the    next    server    to  be    processed. 

B.       TYPE   AND    VOLOHE    OF   CHANGES 

The  relationship  hetween  the  type  of  change  performed  in 
the  CFMT  program  and  its  impact  in  terms  of  addition  and 
updating  of   procedures   is  illustrated  in    Table   I 


TYPE 


TOTAL 


TAB1E  I 
Type  and  Effect  of  Changes 


IMPACT  ON  THE  PROGRAM  PROCEDURES 


OF 

NEE 

MA  JO  R 

MINOR 

TOTAL  {%) 

CHANGE 

CHANGE 

CHANGE 

AEAFSIVE 

13 

10 

6 

29   (64) 

PERFECTIVE 

U 

7 

2 

13   (29) 

CORRECTIVE 

- 

- 

3 

3   (7) 

17 


17 


11 
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Host  of  the  program  modifications  were  accomplished  for 
development  of  the  sinulator  modeling  capability  and  program 
user  friendliness.  The  effect  of  the  work  performed  to 
correct  errors  in  the  original  program  is  not  significant 
compared  to  the  activity  devoted  to  the  satisfaction  of  new 
requirements. 

E.       IBPACT   OB   THE    CPHT    USER'S      MANUAL 

In  order  to  reflect  the  enhancement  of  the  CrMT 
simulator  as  a  result  of  the  changes  described  in  this 
chapter,  rewriting  of  the  CPMT  user's  manual  was  required. 
The  next  chapter  presents  the  new  version  of  the  CPMT  user's 
manual   which  replaces  the   original   described   in   Ref.2. 
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IV.  CPMT  USER'S  MANUAL 

This  chapter  is  intended  for  CPMT  program  end  users,  and 
includes  all  the  documentation  needed  to  employ  the 
simulator  properly.  This  new  version  of  the  user's  manual 
reflects  the  changes  made  through  the  maintenance  effort 
described  in  chapters  2  and  3,  and  provides  the  information 
users  need  to  prepare  a  simulation  model  and  run  the 
program. 

A.   GE1EBAL  DESCBIPTICH  OP  THE  CPMT 

CEMT  is  a  net work-of -queues  simulator  designed  for 
simulation  of  computer  systems.  The  program  creates  and 
maintains  a  database  which  can  store  specifications  for  99 
distinct  models.  Computer  systems  are  modeled  as  collections 
of  server  groups  which  represent  system  components  such  as 
CPU  and  I/O  devices. 

After  modeling  the  computer  system  and  entering  the 
model  parameters  in  the  data  base,  users  can  check  for 
correctness  of  the  model  specification  before  running  the 
simulation  model.  The  program  includes  a  built-in  debugging 
aid  for  simulation  design  which  produces  appropriate  error 
messages  if  the  model  specification  does  not  meet  the 
established  requirements. 

Correct  simulation  models  will  run  for  a  period  of  time 
determined  by  the  user.  Upon  completion  of  the  simulation 
run,  the  program  outputs  a  number  of  statistics  related  to 
the  behavior  of  the  simulated  system.  Users  may  then  study 
the  output  and  decide  whether  to  rerun  the  simulation,  to 
change  the  model  parameters  or  to  terminate  the  program. 
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A  detailed  description  of  the  program  input  ,  output  and 
possible  error  conditions  is  presented  in  the  next  sections. 

B.   HGEEI  DESIGI  AHD  SPECIFICATION 

The  specification  of  a  simulation  model  to  be  run  by  the 
CPMT  simulator  involves  characterizing  the  computer  system 
configuration  and  the  workload  handled  by  the  system. 

The  system  configuration  is  characterized  as  a  network 
of  hardware  resources (CPU, I/O  devices  or  terminals)  and 
software  resources  (level  of  programming  and  scheduling 
algorithms) .  The  workload  which  is  processed  by  the  system 
is  represented  in  terms  of  standard  job  types, 
priorities, arrival  rates  and  demands  placed  on  the  various 
resources. 

All  data  parameters  to  describe  the  model,  except  the 
level  of  programming,  are  grouped  into  three  record  types 
for  data  input  and  data  base  storage.  The  level  of 
programming  (number  of  circulating  jobs  in  a  closed  network) 
is  not  stored  in  the  data  base  and  its  specification  is 
entered  interactively  as  the  simulation  model  is  run. 

Each  model  is  assigned  a  simulation  model  number  between 
1  and  99.  The  range  1  to  49  is  to  be  used  for  open  network 
models  and  the  range  50  to  99  for  closed  network  models.  Ihe 
simulation  number  is  used  to  identify  a  particular 
simulation  model  in  the  program  data  base  and  is  ccmmcn  to 
all  the  record  types  developed  to  describe  a  given  model. 

The  servergroup  record  describes  the  nodes  of  the 
computer  system  being  modeled  and  the  job  type  and  routing 
records  describe  the  work  to  be  processed  by  the  system. 

The  rest  of  this  section  presents  a  detailed  explanation 
cf  model  design  and  data  input  format  for  simulation  of 
models  by  the  CPMT.  An  example  of  the  model  design  process 
for  a  simple  computer  system  is  provided  for  better 
understanding. 
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1  .   Timing 

As  the  internal  clock  of  the  CPMT  is  an  integer, 
arrival  rates  and  service  rates  mast  be  represented  by 
integer  values.  The  designer  of  the  simulation  model  must 
use  (scale  up)  these  time  units  in  a  consistent  way 
throughout  the  model  design  for  correct  output  statistic 
results. 

2.   Servergroup  Record 

Each  hardware  resource  (or  node)  of  the  computer 
system (or  network)  is  described  by  a  servergroup  record. 
Each  servergroup  is  comprised  of  one  or  more  servers  and  is 
serviced  by  a  single  gueue. 2 

The  maximum  gueue  length  for  the  servergroup  is 
assumed  to  be  infinite.  The  assignment  of  a  job  to  a  server 
within  a  servergroup  is  automatically  processed  by  the 
program  using  the  following  algorithm:  servers  are  assigned 
to  seguential  numbers  starting  by  one;  a  job  is  assigned  to 
the  idle  server  with  the  lowest  server  number. 

The  servergroup  parameters  are  described  below: 
SERVERGROUP  NUMBER  —  the  simulator  has  the  capability  to 
model  up  to  9  distinct  servergroups.  The  user  must  assign 
one  of  the  available  server  group  numbers  (range  1  to  9)  . 

NUMEEE  OF  SERVERS  —  the  simulator  has  the  capability  to 
model  a  maximum  of  99  servers  within  a  servergroup.  The 
user  specifies  the  number  of  servers  for  each 
servergroup (range  0  to  99);  for  each  servergroup  numter 
not  used  in  the  model  the  user  must  specify  "0"  as  the 
number  of  servers  for  that  servergroup. 


2The  order  in  which  the  jobs  are  served  is  stored  in  the 
routing  record 
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3-   Job  Type  Record 

Modeling  of  the  system  workload  is  done  by  first 
partitioning  the  jobs  into  classes  according  to  their 
processing  characteristics.  Each  class  is  described  by  a  job 
type  record  and  multiple  routing  records  which  are  linked  to 
that  jot  type  record.  The  job  type  data  parameters  include 
job  type  number,  job  type  priority,  arrival  rate  and 
distribution  type  and  are  described  below. 

JOB  TYPE  NUMBER  —  each  job  type  is  assigned  a  number 
from  1  to  99  for  purposes  of  identification.  The  program 
assigns  sequential  job  type  numbers  as  the  job  type 
record  data  are  entered. 

JOB  TYPE  PRIORITY  —  for  each  job  type  the  user  specifies 
the  priority  which  that  job  will  have  in  the  system.  The 
priority  range  is  from  1  to  10  with  1  being  the  highest. 
Specification  of  different  job  type  priorities  is 
insignificant  if  the  jobs  are  to  be  served  at  the 
servergroups  with  a  nonpriority  dependent  gueueing 
discipline. 

ARRIVAL  DISTRIBUTION  TYPE  AND  DISTRIBUTION  PARAMETER  — 
in  order  to  describe  the  job  type  arrival  rate  into  the 
system,  the  user  selects  the  distribution  type  and 
distribution  parameter.  These  parameters  are  not  entered 
for  closed  network  models  (because  in  a  closed  network 
there  are  no  departures  or  arrivals,  and  in  order  to 
model  this,  CPMT  automatically  schedules  one  arrival  at 
exactly  the  time  cf  every  departure) .  The  distribution 
type  and  distribution  parameter  options  are  discussed  in 
more  detail  later  in  this  chapter. 


60 


**  •   Routing  Record 

Each  routing  record  represents  one  step  in  the 
routing  of  a  job  type  and  has  two  functions,  to  describe  the 
service  to  be  processed  at  each  servergroup  and  to  provide 
the  branching  probabilities  from  that  servergroup  to  all  the 
ether  servergroups  in  the  system. 

In  order  to  model  the  entrance  and  exit  of  jobs  into 
the  system,  two  dummy  servergroups,  0  and  1 0,  must  be 
descibed  as  part  of  model  design.  However,  no  service  is 
performed  in  these  servergroups  and  so  there  is  no 
specification  of  server  records  for  these  servergroups.  The 
entrance  and  exit  servergroups  must,  however,  be  included  in 
the  branching  probabilities.  The  routing  record  parameters 
are  : 

SERVICE  DISTRIBUTION  TYPE  and  DISTRIBUTION  PARAMETER  — 
the  service  demand  for  the  job  type  is  defined  ty  a 
distribution  type  and  a  corresponding  parameter.  The 
detailed  discussion  of  these  parameters  is  provided  later 
in  this  chapter  under  a  separate  header. 

QUEUEING  DISCIPLINE3  —  the  queueing  discipline  in  which 
the  jot  type  is  served  is  identified  by  an  integer  value 
btween  1  and  7.  The  gueueing  disciplines  currently 
implemented  in  the  CPMT  and  the  corresponding 
identification  code  are  listed  in  Figure  4.1. 

ROUTING  PROBABILITIES  —  the  routing  probability  is 
implemented  as  a  one  dimensional  array  of  integers.  The 
entries  in  this  array  represent  the  probability  that  the 
particular  job  type  will  go  from  the  current  server  group 
to  each  of  the  other  server  groups  in  the  model.  The 
routing  probability   is  an  integer  from   0  to   100.   The 


3the  gueueing  discipline  is  stored  in  the  routing  record 
rather  than  in  the  servergroup  record  for  CPMT  design 
convenience. 
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CODE      QUEUEING  DISCIPLINE  ABREV. 


1  First  Come  First  Served  (FCFS) 

2  Last  Come  First  Served  (LCFS) 

3  Nonpreemptive  Priority  (NP) 

4  Shortest  Proc.  Time  First  (SPIF) 

5  Lowest  Weighted  Proc. Time  First  (LWPTF) 

6  Processor  Sharing  (PS) 

7  Served  in  Randcm  Order  (SIRO) 


Figure  4. 1    Queueing  Disciplines 

routing  record  design  must  meet  established  requirements 
which  are  discussed  further  in  the  "routing  design 
rules". 

5 •   Distribution  Specification 

To  describe  the  arrival  rate  of  job  types  or  their 
service  rates  at  the  servergroups,  the  user  selects  one  of 
three  available  distribution  types,  DETERMINISTIC, 
EXPONENTIAL  or  UNIFORM,  and  also  provides  a  parameter  (range 
1  to  99999)  to  specify  the  value  (s)  of  the  rate.  The 
distribution  types  and  corresponding  distribution  parameters 
are  listed  in  figure  4.2. 

6 .   Routing  De si cjn  Rules 

The  routing  design  for  each  job  type  must  satisfy 
the  following  rules: 

a   routing    record   is   required   for    the   entrance 
servergroup  (SG  0).   Since  no   processing  is  done  at  this 
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CODE 

1 

DISTRIBUTION 

PARAMETER 

i 

DETERMINISTIC 

DETERMINATE 

VALUE 

2 

EXPONENTIAL 

MEAN   VALUE 

3 

UNIFORM 

UPPER  BOUND 

Figure  4.2    Distribution  Types  and  Parameters 

server,  no  values  are  assigned  to  the  service 
distribution  type  or  distribution  parameter,  but  routing 
probabilities  frcm  this  servergroup  to  the  working 
servergroups  (SG  1  through  9)  must  be  provided. 

-  jobs  must  be   routed  to  the   exit  servergroup   (SG  10) 
from  at  least  one  working  servergroup;   no  routing  record 
is   required    for  the    exit   servergroup   because  no 
processing  is  done  at  this   servergroup  and  because  a  job 
is  not  routed  to  any  other  servergroup. 

the  sum  of  the  routing  probabilities  from  a  given 
servergroup  to  all  others  must  be  equal  to  100. 

the  probability  of  routing  a  job  from  a  given 
servergroup  to  itself  must  not  be  equal  to  100  to  avoid 
generating  a  job  which  never  complete  processing. 

-  if  a  job  type  is  routed  to  a  servergroup,  then  a 
routing  record  must  exist  for  that  job  type  from  that 
servergroup. 
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7-   Data  Input  Format 

In  order  to  facilitate  the  online  input  of  the  model 
data  specification  and  provide  documentation  of  the  model, 
the  user  should  fill  out  one  servergroup  record  data  form 
shown  in  Fig  4.3  per  simulation  model,  and  one  job  type  and 
routing  record  data  form.  Fig  4.4  ,  for  each  job  type  in  the 
model. 


Simulation  number  : 

Server  Group  Number 

1 
2 
3 
4 
5 
6 
7 
3 
9 


Number  of  Servers  : 


Figure  4.3    Servergroup  Record  Data  Forn 


8.   Example  of  Model  Design 

An  illustration  of  the  model  design  process  is 
presented  below,  using  a  computer  system  described  by  SAUEE 
[Ref.  1  :p.376].  Part  of  the  model  specifications  will  also 
be  used  as  an  exacple  for  the  user  program  dialogue 
described  in   the  next  section   "HOW  TO  RON   THE  SIMULATOR". 


64 


Simulation  Number  :  Job  Type  Number  : 

***************    job  TYPE  RECORD    ***************** 
Arrival  Dist 
Dist  Param 

Priority 
*************** 


Servergroup 
Service  Dist 
Dist  Param 
Queue  Disc 
Routing  To 

SG  1 

SG  2 

SG  3 

SG  a 

SG  5 

SG  6 

SG  7 

SG  8 

SG  9 

SG  10 


ROUTING  RECORD 


1 


***************** 

5         6         7         8         9 


Figure   4.4        Job  Type   and   Routing   Record  Data   Form 

This    model    was    also    simulated    for    validation   of    CPMT    and    the 
results   are   discussed   in   Chapter    5. 

a.      The    System 

The  computer  which  is  to  be  modeled  is  a 
multiprogrammed  system  having  four  memory  partitions.  The 
system  has  a  single  processor  and  two  I/O  devices,   a  floppy 
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disk  and  a  hard  disk,  sharing  a  common  channel.  The  hardware 
organization  is  illustrated  in  Figure  4.5. 


c  pu 


CHANNEL 


hIARD 
DiSK 


FLOPPY 

DISK 


Figure  4.5    Computer  System  H/I  Organization 

The  CPU  scheduling  algorithm  is  a  low  overhead 
Round  Robin  which  can  be  considered  to  be  equivalent  to 
Processor  Sharing  (PS)  and  the  I/O  reguests  are  served  in  a 
First  Come  First  Served  basis.  The  system  is  to  be  simulated 
with  all  memory  partitions  in  use.  The  degree  of 
multiprogramming  ,  average  service  times  and  branching 
probabilities  derived  from  the  system  accounting  data 
recorded  during  a  period  of  heavy  workload  are  illustrated 
in  Figure  4.6. 

t.   The  Model 

Assuming  that  there  is  a  sufficient  Lacklcg  of 
jobs  and  there  is  a  sufficient  memory  contention  that  the 
degree  cf  multiprogramming  is  essentially  constant,  the 
system  can  be  modeled  by  a  closed  gueueing  central  server 
network  model.  The  central  processor  is  represented  by 
servergroup  1  preceeded  by  a  gueue,  and  the  disks  are 
represented  as   servergroups  2   and   3,    each  one   with   a 
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DEGREE  OF  MULTIPROGRAMMING  4 

AVERAGE  CPU  SERVICE  TIME  0.05  sec 

AVERAGE  FLOPPY  DISK  SERVICE  TIME  0.220  sec 

AVERAGE  HARD  DISK  SERVICETIME  0.019  sec 

PROBABILITY  OF  JOB  COMPLETION 

AFTER  DISK  SERVICE 0.125 

PROBABILITY  OF  FLOPPY  ACCESS  0.1 


Figure  4. 6    Data  Parameters 

respective  queue.    Servergroups  2   and  3  are  organized   in 

parallel  with   respect   to    the   central  processor.    Two 

additional  dummy  servers,  entrance  (SG  0)  and  exit  (SG  10) 
are  included  as  reguired  by  the  CPMT.  The  model  is 
illustrated  in  Fig  4.7. 

Service  times  are  assumed  to  be  exponentially 
distributed. 

c.   Input  Model  Parameters 

As  the  system  is  represented  by  a  closed 
network,  a  simulation  number  in  the  range  50  to  99  must  be 
assigned  to  the  sinulation  model.  For  this  example  the 
simulation  number  60  was  arbitrary  chosen. 

SERVERGROUP  RECORE  —  the  model  has  three  servergroups 
SG1  (CPU),  SG2  (FLCPPY  DISK)  and  SG3  (HARD  DISK)  each  one 
consisting  of  a  single  server.  The  servergroup  record 
data  form  for  this  model  is  displayed  in  figure  4.8. 
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Figure    4-7        Computer   System   Hodel 
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Figure   4.8        Model   Servergroup   Data   Form 
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JCB  TIPE  RECORD  —  the  computer  system  has  only  one  job 
type  which  will  te  designated  as  job  type  1 ,  and  since 
there  is  only  one,  the  priority  is  insignificant.  As  the 
model  is  a  closed  network,  arrival  distribution  type  and 
distribution  parameter  are  not  considered. 

ROUTING  RECORDS  —  three  routing   records  are  required  to 

describe  the   service  processed   at  the   servergroups  and 

routing  of   jobs  through   the  system.    As  stated   in  the 

routing  design  rules  an   additional  servergroup  (entrance 

servergroup)  record  is  required  for  job  routing  purpose. 

The  smallest  amount  of  time  represented   in  the 

model,  as  listed  in  Fig  4.6  is  the  hard  disk  service,   which 

is  0.019.   Therefore,   all  the  time  values  are  multiplied  by 

1000   so   that   they   are   all   integers   (time    unit   = 

millisecond).  The  mean  service  times  are  then  : 

SG  1  50 

SG  2  220 

SG  3  19 

The  routing  probabilities  to  be  assigned  are 
derived  from  data  shown  in  Fig  4.6  ,  applying  the  routing 
design  rules  for  CPHT.  As  the  processing  of  jobs  is 
initiated  by  CPU  service,  the  routing  probability  from  the 
entrance  servergroup  SG0  to  SG 1  is  100.  The  routing 
probability  from  SG 1  to  SG2  is  10  and  from  SG1  to  SG3  is  90 
(100  -  10).  As  the  probability  of  job  completion  after  disk 
service  is  0.125,  the  rounded  value  in  the  range  0  to  99  is 
13.  Thus  the  routing  probabilities  from  SG2  and  SG3  to  the 
exit  servergroup  SG10  are  13.  The  remaining  routing 
probability  (for  new  CPU  service)  is  87,  thus  the  routing 
probabilities  from  SG2  and  S3  to  SG1  are  37.  The  job  type 
and  routing  records  data  form  for  the  model  are  illustrated 
in  Fig  4.9. 
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Simulation  Number    :    60  Job    Type    Number    :    1 

***************** 


*************** 

JOB 

TYPE 

RECOH 

Arrival  Dist  : 

: 

D is t  Par am   : 

: 

Priority 

:   1 

*************** 

ROUTING 

RECORD 

Servergroup  : 

0 

1 

2 

3 

Service  Dist: 

- 

2 

2 

2 

Dist  Param   : 

- 

50 

220 

19 

Queue 

Disc   : 

- 

6 

1 

1 

Routing  To   : 

SG 

1 

I00 

0 

87 

87 

SG 

2 

0 

10 

0 

0 

SG 

3 

0 

90 

0 

0 

SG 

4 

0 

0 

0 

0 

SG 

5 

0 

0 

0 

0 

SG 

6 

0 

0 

0 

0 

SG 

7 

0 

0 

0 

0 

SG 

8 

0 

0 

0 

0 

SG 

9 

0 

0 

0 

0 

SG 

10 

0 

0 

13 

13 

***************** 
5         6         7         8         9 


Figure  4.9    Model  Job  Type  and  Routing  Forn 

C.   HOW  TO  BDI  THE  SIMULATOR 

CPMT  runs  on  the  VAX/VMS  Computer  Science  Department 
Computer  at  NPS.  To  execute  the  program  after  logging  onto 
the  computer,  enter  the  command  RUN  CPMT  in  response  to  the 
$  prompt. 


70 


The  program  initially  displays  to  the  user  the  MASTER 
MENU  of  program  options  presented  in  Fig.  4.10  The  user 
enters  the  integer  value  corresponding  to  the  option 
desired.  Whenever  an  invalid  option  is  entered  the  meru  is 
redisplayed.  A  description  of  each  option  follow  under 
separate  headings. 


1  -  ENTER  NEW  SIMULATION  NUMBER 

2  -  UPDATE  SIMULATION  SPECIFICATIONS 

3  -  CHECK  SIMULATION  SPECIFICATIONS 

4  -  RUN  SIMULATION  MODEL 

5  -  PRINT  ALL  DATA  BASE 

6  -  PRINT  DATA  BASE  FOR  A  SINGLE  MODEL 

7  -  DELETE  SIMULATION  MODEL 

8  -  COPY  SIMUIATION  MODEL 

9  -  DISPLAY  SIMULATION  MODEL  SPECIFICATIONS 
0  -  EXIT  CPMT  ENVIRONMENT 


Figure  4.10    Master  Menu  Options 

At  several  points  in  the  program,  the  user  directs 
program  control  hy  responding  to  questions  which  have  "yes" 
or  "no"  answers.  The  convention  for  the  CPMT  program  is  that 
the  user  enters  either  the  uppercase  or  lowercase  "y"  for  a 
"yes"  response  and  any  other  character  for  a  negative 
response. 

Each  simulation  mcdel  is  identified  by  a  unique  integer 
value  called  the  simulation  number.  The  user  may  assign  a 
simulation  model  an  integer  number  in  the  range  1  to  49  for 
CPEN  NETWORK  MODELS  and  50  to  99  for  CLOSED  NETWORK  MODELS. 
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1-   Enter  a  New  Simulation  Number 

This  function  is  to  be  selected  if  the  user  wishes 
to  add  a  new  simulation  model  to  the  simulator  data  base. 

Upon  entry  of  the  integer  value  "1"  corresponding  to 
this  option  the  program  displays  either  the  simulation 
numbers  already  existing  in  the  data  base,  or  the  message  : 

NO  SIMULATION  NUMEERS  IN  DATA  BASE 

and  prompts  for  entering  of  the  simulation  number.  At  this 
point  the  user  enters  the  desired  simulation  number  for  the 
new  model.  If  a  simulation  number  out  of  the  1  to  99  range 
is  entered,  the  message 

EREOE  IN  INPDT 

is  displayed  and  the  simulation  number  is  prompted  again. 
Otherwise,  if  the  user  enters  a  simulation  number  already 
existing  in  the  data  base,  the  message 

SIMULATION  MODEL  NUMBER  ALREADY  EXISTS  IN  DATA  BASE 

is  displayed  and  the  program  will  return  to  the  Master  Menu 
on  the  entry  of  any  character.  Otherwise  the  update  options 
are  presented  to  the  user  in  a  menu  format,  UPDATE  MENU, 
similar  to  that  of  the  MASTER  MENU.  The  update  menu  options 
are  listed  in  Fig  4.11  and  are  explained  further  in  this 
section  under  a  separate  header. 

2 .   Update  Model  Specifications 

This  function  is  to  be  selected  if  the  user  wishes 
to  update  the  specifications  cf  a  simulation  model  already 
existirg  in  the  simulator  data  base.  This  function  is  also 
automatically  selected  after  a  new  simulation  number  has 
been  selected. 
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1 

ADD  JOB  TYPE  RECORD 

2 

- 

ADD  ROUTING  RECORD 

3 

- 

ADD  SERVERGROUP  RECORD 

a 

- 

DELETE 

JCE  TYPE  RECORD 

5 

- 

DELETE 

ROUTING  RECORD 

6 

- 

DELETE 

SERVERGROUP  RECORD 

1 

- 

CHANGE 

JOB  TYPE  RECORD 

8 

- 

CHANGE 

RCCTING  RECORD 

9 

- 

CHANGE 

SERVERGROUP  RECORD 

0 

— 

RETURN 

TO  MASTER  MENU 

Figure  4.11    Update  Menu  Options 

Upon  entry  of  the  integer  value  2  corresponding  to 
this  option,  the  program  prompts  th€  user  to  input  the 
simulation  number.  If  the  user  enters  a  simulation  number 
that  does  not  exist  in  the  data  base  the  following  message 
is  displayed  : 

SIMULATION  MODEL  EOES  NOT  EXIST  IN  DATA  BASE 

In  this  case  program  control  returns  to  the  Master  Menu 
after  entry  of  any  character,  otherwise  the  update  options 
are  presented  by  the  UPDATE  MENU. 

3.   Check  Simulation  Specifications 

This  option  is  used  as  a  debugging  aid  to  check  if  a 
given  simulation  model  meets  the  specification  requirements 
for  a  successful  simulation  run. 

The  program  will  prompt  the  user  to  input  the  number 
of  the  simulation   model  to  be  checked.   As   the  user  enters 
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the  simulation  model  Dumber,  the  existence  of  data  records 
and  observation  of  the  routing  rules  are  tested  for  the 
specified  model.  If  the  simulation  model  does  not  meet  the 
requirements  the  following  message  is  displayed  : 

SIMULATION  SPECIFICATIONS  DID  NOT  CHECK 
EBEOE  MESSAGES  IN  FILE  OUTFILE.DAT 

The  error  messages  will  help  the  user  to  eliminate  the  model 
specification  deficiencies.  The  list  of  possible  error 
messages  is  presented  in  Figure  4.12. 


---------  —   _..,._,,   — 

1. 

Simulation  Number  Does  Not  Exist. 

2. 

No  Server  Group  Record  Exists. 

3. 

No  Job  Type  Exists. 

4. 

Jcb  Numbers  Are  Not  Seguential. 

c 

Server  Group ,  Job  Type Routing  Loop. 

€. 

No  Routing  Records  Exist  for  Job  Type . 

7. 

No  Server  Group  0  Routing  Record  For  Job  Type . 

8. 

Job  Type not  Routed  to  Exit  Server  Group. 

9. 

Job  TYpe Routed  To  But  Not  From  Server  Group . 

Figure  4.12    Simulation  Specification  Error  Messages 

If  the  simulation  model  is  correctly  specified  the  following 
message  is  displayed  : 

SIMULATION  SPECIFICATIONS  CHECK 

In  both  cases  the  program  control  returns  to  the  Master  Menu 
by  entry  cf  any  character. 


74 


4 .   Bun  a  Simulation  Model 

This  option  is  selected  if  the  user  wishes  to 
execute  the  simulation  of  a  model. 

The  program  will  first  prompt  the  user  to  input  the 
number  of  the  model  to  be  run  and  then  displays  a  menu  with 
the  options  for  specification  of  run  duration,  number  of 
jobs,  clock  time  or  number  of  events  (  or  the  last  two 
options  for  closed  network  models) .  Upon  entering  the  option 
the  program  displays  the  prompt  for  entering  of  the 
corresponding  parameter.  As  the  user  enters  the  number  of 
jobs,  simulation  tiae  or  number  of  events  to  be  processed, 
depending  on  the  specification  type  selected,  the  program 
prompts  for  a  seed  value.  The  seed  will  be  used  as  initial 
input  into  the  system  random  number  generator.  The  random 
numbers  in  turn  are  used  as  input  into  program  functions 
which  require  random  variables. 

At  this  point  the  program  asks  if  the  user  wishes 
the  program  to  specify  the  interval  of  time  for  statistics 
(the  program  can  produce  statistics  about  the  behavior  of 
the  simulated  system  for  a  period  of  time  during  simulation 
or  for  all  simulation  time) .  If  the  user  response  is 
affirmative,  the  start  time  and  stop  time  for  gathering 
statistics  will  be  reguested. 

If  the  simulation  model  to  be  run  is  a  closed 
network,  the  program  will  ask  the  user  to  input  an 
additional  model  specification,  the  degree  of  programming. 
The  degree  (or  level)  of  programming  represents  the  number 
of  jots  to  be  processed  in  the  closed  network  and  is 
prompted  for  each  job  type  in  the  model.  A  complete  example 
of  the  user  program  dialogue  for  execution  of  a  closed 
network  simulation  model  is  illustrated  in  Fig.  4.13. 

Before  executing  the  simulation  model  the  program 
will  check  the   simulation  specifications.   If  the   model  is 
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not      correctly      specified      the      following      message      will      be 
displayed    : 

SIMULATION    MODEL    NOT    EXECUTED 

SIHULATION    MODEL    SPECIFICATIONS    DO    NOT    CHECK 

ERROR    MESSAGES    IN    FILE    OUTFILE.DAT 


ENTER    SIMULATION    NUMBER    OF    MODEL    TO    EXECUTE 

65 

ENTER  SPECIFICATION  TYPE  FOR  RUN  DURATION 

1-  CLOCK  TIME 

2-  NUMBER  OF  EVENTS 

1 

ENTER  SIMULATION  RCN  DURATION 

150000 

ENTER    THE    SEED    YO C    WANT    TO    USE 

45367 

DO  YOU  WISH  TO  SPECIFY  THE  INTERVAL  TIME  FOR  GATHERING 
STATISTICS  ?  y/- 

Y 

ENTER  START  TIME  ECR  STATISTICS 

300 

ENTER  STOP  TIME  FOR  STATISTICS 

120000 

ENTER  DEGREE  OF  PfCGRAMMING  OF  JOB  TYPE  1 

4 


Figure  4.13    Example  of  Execute  Simulation  Model  Dialogue 


The  possible  error  messages  are  those  already  referenced  and 
illustrated  in  Figure  4.12.  Otherwise  if  the  simulation  run 
duration   is  selected  by  clock   time  and   no  jobs   complete 
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within  the  simulation  period,  the  following  error  message 
will  be  displayed  : 

ERROR  -   SIMULATION  MODEL  EXECUTED  BUT 

NO  JOBS  COMPLETED  DURING  SIMULATION  TIME 

In  both  cases  the  program  returns  to  Master  Menu  by  entry  of 
any  character. 

If  the  execution  is  successful  the  statistical 
output  will  be  written  in  the  file  OUTFILE.DAT  and  the 
following  message  will  be  displayed  : 

SIMULATION  MODEL  EXECUTED 

OUTPUT  STATISTICS  IN  FILE  OUTFILE.DAT 

DO  YOU  FISH  TO  RUN  THE  SIMUIATION  AGAIN  ?  y/- 

If  an  affirmative  response  is  entered  the  program  dialogue 
will  be  repeated  for  rerunning  the  same  simulation  model, 
otherwise  the  user  is  given  the  option  of  exiting  the 
function  or  attempting  to  run  other  simulation  model. 

The  output  statistics  include  minimum,  maximum,  mean 
and  standard  deviation  of  time  in  system  and  time  in  gueue, 
throughput  and  mean  number  of  jobs  in  the  system  for  all 
jobs  and  for  each  job  type,  and  maximum,  minimum  and  mean 
gueue  size  and  utilization  by  server  group  and  server  within 
a  server  group.  An  example  of  the  output  report  format  is 
illustrated  in  Figure  4.14. 
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5 •   ili^t  Data  Base 

This  option  is  used  for  monitoring  of  the  CPMT  data 
tase  workload. 

Opon  selection  of  this  option,  a  printout  of  the 
entire  indexed  sequential  data  base  is  written  to  the  file 
OUTFILE.DAT.  The  program  control  returns  to  Master  Menu  by 
entering  of  an  arbitrary  character.  If  the  user  wishes  a 
hard  ccpy  a  print  out  must  be  requested  from  outside  the 
CPMT  environment. 

6-   ££ini.  Oata  Base  for  a  Single  Model 

This  function  is  to  be  selected  if  the  user  wishes  a 
printout  of  a  given  simulation  model  specification. 

Upon  selection  of  this  option,  the  program  asks  the 
user  to  input  the  simulation  number.  Upon  entry  of  the 
simulation  model  number,  the  program  attempts  to  find  the 
simulation  model  in  the  data  base.  If  the  simulation  model 
exists,  the  program  writes  all  the  records  for  that  model  to 
the  file  OUTFILE.DAT,  and  displays  the  message: 

MCDEI  SPECIFICATICN  IN  FILE  OUTFILE.DAT 

The  user  then  requests  a  printout  of  the  file  from  outside 
the  CPMT  environment.  If  the  simulation  model  number  is  not 
found  the  message 

SIMULATION  MODEL  DOES  NOT  EXIST  IN  DATA  3ASE 

is  displayed.  In  either  case  the  user  is  given  the  option  of 
exiting  this  function  ,  or  attempting  to  print  another 
simulation  model. 

"7 •   Delete  a  Simulation  Model 

This  option  is  used  to  delete  a  complete  simulation 
model  from  the  data  tase. 
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Upon  selection  of  this  option  the  program  prompts 
for  entry  of  the  simulation  model  number.  After  the  user 
enters  the  simulation  number  the  program  attempts  to  find 
the  model  in  the  data  base.  If  the  number  of  the  model  does 
not  exist  an  error  message  is  displayed,  otherwise  the 
program  gives  the  user  the  option  of  deleting  the  model.  If 
the  user  responds  affirmatively  the  program  deletes  all  of 
the  records  for  the  chosen  simulation  model  from  the  data 
base  and  displays  the  message: 

SIMULATION  MODEL  DELETED. 

At  the  end  of  the  dialogue  the  user  is  given  the 
option  of  exiting  function  or  attempting  to  delete  other 
simulation  model. 

8 •   Co£2  a  Simulation  Model 

The  copy  option  is  convenient  if  the  user  wishes  to 
compare  the  simulation  results  of  two  models  with  a  few 
changes  in  parameter  specifications.  In  this  case  the  user 
can  copy  one  model  to  a  new  number,  maxe  the  changes  in  the 
copy,  and  maintain  both  model  design  specifications  in  the 
data  base. 

Upon  selection  of  this  option  the  program  displays 
the  prompt  for  entering  the  simulation  model  number  which  is 
to  be  copied  and  the  model  number  of  the  copy.  If  the  number 
of  the  model  to  be  copied  does  not  exist  the  following 
message  is  displayed  : 

SIMDIATION   MODEL  NUMBER  DOES  NOT  EXIST  IN  DATA  BASE 

Otherwise,   if  the  new  simulation  model  number  is  already  in 
the  data  base  the  following  message  is  displayed  : 

SIMULATION  MODEL  NUMBER  ALREADY  EXISTS  IN  DATA  BASE 

If  the  copy  is  successful  the  following  message  is  displayed 

SIMUIATICN  MODEL  COPIED 
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At  the  end  of  the  dialogue  the  user  is  given  the  option  of 
exiting  the  function  or  attempting  to  copy  another 
simulation  model. 

9-   Display  Simulation  Model  Specifications 

This  option  is  used  for  on-line  review  of  simulation 
models. 

Upon  selection  of  this  option  the  program  prompts 
for  entry  of  the  simulation  model  number  and  then  attempts 
to  find  the  model  in  the  data  tase.  If  the  simulation  model 
does  not  exist  an  appropriate  message  will  be  displayed, 
otherwise  the  program  asks  the  user  to  input  the  type  of 
record  to  be  reviewed  {job  type  , routing  or  servergroup) .  If 
the  user  selects  either  the  joh  type  or  the  routing  record, 
the  program  asks  the  user  to  identify  the  job  type  number. 
The  record  data  will  be  directly  displayed  for  the  job  type 
record  and  the  identification  of  the  routing  record  number 
to  be  displayed  will  be  prompted  for  the  routing  record 
option.  If  a  servergroup  record  is  selected  for  user  review 
the  program  asks  the  user  to  identify  the  servergroup  number 
and  then  displays  the  record  data. 

For  all  the  options  the  program  displays  error 
messages  if  the  user  attempts  to  display  data  from 
nonexistent  records. 

After  record  data  review  the  user  is  given  the 
option  of  displaying  another  record  for  the  same  model.  If  a 
negative  response  is  entered,  the  user  is  given  the  option 
of  exiting  the  function,  returning  to  the  Master  Menu 
options  or  displaying  another  model. 

The  user  program  dialogue  for  displaying  a  routing 
record  is  shown  in  Figure  4. 15. 
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DISPLAY    SIMULATION    MGDEL    FUNCTION 

ENTER    SIMULATION    NUMBER    YOU    WISH    TO    DISPLAY    DATA 

60 

ENTER    RECORD    TYPE    YOU    WISH    TO    DISPLAY 

1-  J03  TYPE 

2-  ROUTING 

3-  SERVERGRCUP 
2 

ENTER  JOB  TYPE  NUMBER 

1 

ENTER  ROUTING  RECORD  NUMBER 

3 

(clear   screen) 

(display  of  function  header) 


SEP. VICE  DISTRIBUTION  IS 
DISTRIBUTION  PARAMETER  IS 
QUEUEING  DISCIPLINE  IS 


EXPONENTIAL 
19 
FCFS 


ROUTING  PROB  TO  1  IS 

ROUTING  IRCB  TO  2  IS 

ROUTING  PROB  TO  3  IS 

ROUTING  IRCB  TO  4  IS 

ROUTING  FROB  TO  5  IS 

ROUTING  EROB  TO  6  IS 

ROUTING  PROB  TO  7  IS 

ROUTING  IROB  TO  8  IS 

ROUTING  PROB  TO  9  IS 

ROUTING  IROB  TO  10IS 


87 
0 
0 
0 
0 
0 
0 
0 
0 

13 


DC  YOU  WISH  TO  DISPLAY  MORE  RECORDS 

N 

DO    YCU    WISH    TO    EXIT    FUNCTION    ?    Y/- 

Y 


Y/- 


Figure    4.15        Example  of   Display  Simulation   Model   Dialogue 

10.    Exit   CPMT   Environment 

Upon   selection   of   this      option   the    program   execution 
terminates  and   control   returns   to   the  system 
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11.  Updating  Opticas 

The  functions  for  data  base  record  updating  that  are 
presented  by  the  UPtATE  MEND  are  related  to  a  simulation 
model  number  already  entered  by  the  user  after  either 
selecting  the  option  "Enter  New  Simulation  Number"  or 
"Update  Model  Specifications"  from  the  MASTER  MENU.  The 
Record  Updating  functions  are  explained  below. 

a.   Add  Job  Type  Record 

Upon  selection  of  this  option  the  program 
automatically  accesses  the  simulation  model  in  the  data  base 
to  determinate  the  next  available  job  type  number  for  the 
given  simulation  model  and  assigns  that  number  to  the  job 
type  to  be  added.  The  program  then  requests  the  user  to 
input  the  arrival  distribution  and  distribution  parameters,* 
and  priority  of  the  job  type.  Input  data  values  are  echoed 
as  they  are  entered,  to  allow  the  user  to  detect  incorrect 
data.  The  program  alsc  prompts  for  re-input  of  invalid  data. 

As  the  job  type  record  data  is  entered  the 
program  displays  the  entries  for  review  and  asks  if  the  user 
wishes  to  add  the  job  record.  If  the  user  chooses  to  add  a 
job  type  record  which  exists  in  the  data  base,  the  program 
responds  with  the  message 

RECORD  ALREADY  EXISTS,  NOT  ADDED 

otherwise  the  job  type  record  is   added  to  the  data  base  and 
the  message 

RECORD  SUCCESSFUIIY  ADDED 


4These   two   parameters   are  not   requested   for   closed 
network  models 
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is  displayed.  If  the  user  chooses  not  to  add  the  record  the 
program  displays 

RECCED  NOT  ADDEE 

If  the  job  type  reccrd  is  successful  added  the  option  of 
going  directly  to  the  Add  Routing  Record  function  (see  next 
option)  is  provided.  The  program  control  will  return  to  the 
add  job  type  function  upon  exit  from  the  add  routing  record 
function. 

The  user  may  add  multiple  job  type  records  to  a 
model.  At  the  end  of  every  iteration  of  the  option  dialogue 
the  user  is  given  the  choice  of  exiting  the  function  or 
adding  another  job  type  to  the  model. The  dialogue  for 
addition  cf  a  job  type  record  is  illustrated  in  Fig  4. 16. 

b.   Add  Routing  Record 

This  opticn  can  be  entered  either  directly  from 
the  add  job  type  function  as  explained  above,  or  from  the 
update  menu.  When  the  user  selects  this  option  from  the  add 
job  type  function,  the  routing  records  are  automatically 
added  to  the  job  type  record  just  added.  Otherwise  the 
program  will  ask  the  user  to  identify  the  job  type  number 
for  which  routing  records  are  to  be  added.  If  the  job  type 
number  is  not  found  in  the  data  base  the  following  error 
message  is  displayed: 

ERROR  THE  JOB  TYF1  RECORD  DOES  NOT  EXIST 

If  the  record  job  type  is  found  the  program  requests  the 
user  to  input  the  routing  parameters  of  servergroup  number, 
service  distribution,  distribution  parameter, gueueing 
discipline  and  routing  probabilities. 

As  in  the  "add  job  type  function"  the  input  data 
and  the  entire  data  record  are  displayed  for  user  review. 
The  user  is  given  the  option   of  adding  the  routing  reccrd  . 
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********************************************** 

ADD  JOB  1YPE  RECORD  FUNCTION 

********************************************** 

SIMULATION  MODEL  NUMBER:  60  * 

JOE  TYPE  NUMBER: 1 

ENTER  PRIORITY  FOR  THIS  JOB  TYPE: 
VALID  PRIORITY  CODES  ARE  1  THRU  10 

1 

(clear   screen) 

(display   of    function   header) 

(display   of    the   job    type   record) 

DC    YOU    WISH    TO    ADD    RECORD      TO    THE    DATA    BASE    ?    Y/- 

Y 

RECORD  SUCCESSFUL  ADDED 

DO  YOU  WISH  TO  ADD  ROUTING  RECORDS  FOR  THIS  JOB  TYPE? 

N 

DO  YOU  WISH  TO  EXIT  FUNCTION  ?  Y/- 

Y 

*  As  the  model  is  a  closed  gueueing  network 

arrival  distribution  type  and  distribution  parameter 
are  not  prompted 


Figure  4. 16    Add  Job  Type  Record  Dialogue 

If  the  user  chooses  to  add  an  existing  routing  record,  the 
record  is   not  added  and  an  error  message  is  displayed. 

At  the  end  of  the  function  dialogue  the  user  has 
the  ottion  of  exiting  the  function  or  adding  another  routing 
record  tc  the  model. 

An  example  of  the  user  program  dialogue  for 
adding  a  routing  record  with  selection  from  the  UPDATE  MENU 
is  displayed  in  Figure  4. 17. 
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ADD    ROOTING    RECORD    FUNCTION 

SIMULATION    MODEI    NUMBER:     60 
ENTER    JOE   TYPE    NUMBER    OF    ROOTING    RECORDS    TO    BE    ADDED 
1 

ENTER    ROUTING    RECORD    SERVER    GROUP    NUMBER: 
2 


ENTER    SERVICE    RATE   DISTRIBOIION: 


1-DETERMINATE 
2- EXPONENTIAL 
3-ONIFORM 


ENTER    EXPONENTIAL    EISTRIBOTION    MEAN: 

220 

ENTER    QUEUEING    DISCIPLINE: 

1-riRST    COME    FIRST    SERVED 
2-LAST    COME    FIRST    SERVED 
3-NONPREMPTIVE    PRIORITY 
4-SHORT.    PROC.    TIME    FIRST 
5-LOW.    WEI.  PROC.  TIME    FIRST 
6-PROCESSOR    SHARING 
7-SERVICE    IN    RAND.     ORDER 

1 


[FCES) 
LCFSJ 
NP) 
SPTF) 
LWPTF) 
PS) 

:siro) 


ENTER  THE  ROUTING  PROBABILITY  FROM  SERVER  GROUP  2  TO 

SEFVER  GROUP 

SERVES  GROUP 

SEFVER  GROUP 

SERVER  GROUP 

SERVES  GROUP 

SERVER  GROOP 

SERVER  GROUP 

SERVER  GROUP 

SEFVER  GROUP 

SERVER  GROUP 

(clear  screen) 

(display  of  function  header) 

(display  of  the  routing  record) 

TO  ADD  RECORD  TO  THE  DATA  BASE  ?  Y/- 


1 , 

:    87 

2: 

:       0 

3: 

■       0 

4. 

:       C 

5 

:      0 

6: 

0 

7: 

:      0 

8: 

0 

9: 

0 

10: 

:     13 

DO  YOU  WISH 
Y 


DO  YOO  WISH  TO 
Y 


RECORD  SUCCESSFOL  ADDED 
EXII  FUNCTION  ?  Y/- 


Figure  4. 17    Add  Routing  Record  Dialogue 
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c.  Add   Servergroup    Record 

This  option  is  used  to  add  a  servergroup  record 
to  a  simulation  model. 

Upon  selection  of  this  option  the  program 
prompts  the  user  for  entering  the  number  of  servers  for  each 
server  group  in  the  system  and  then  displays  the  record  for 
user  review.  At  this  point  the  .user  is  given  the  option  of 
adding  the  record  to  the  data  base.  If  the  user  chooses  not 
to  add  the  record,  the  message: 

RECORD  NOT  ADDED 

is  displayed,  otherwise  the  program  will  check  for  the 
existance  of  a  servergroup  record  for  that  model  in  the  data 
base  before  adding  the  new  record.  Depending  on  whether 
there  is  an  existing  servergroup  record  for  that  model,  the 
record  is  added  or  not  and  one  of  the  following  messages  is 
displayed  : 

RECORD  SUCCESSFULLY  ADDED 

or 

RECORD  ALREADY  EXIST;  NOT  ADDED 

This  function  is  not  repeated  because  there  is 
only  one  allowed  servergroup  record  per  simulation  model, 
and  the  user  is  returned  to  the  Update  Menu  on  entry  of  a 
character. 

An  example  of  the  user  program  dialogue  for 
addino  a  servergroup  record  is  illustrated  in  Fig.  4.18. 

d.  Delete  Jot  Type  Record 

This  option  is  used  to  delete  a  job  type  record 
from  the  data  base. 

Upon  selection  of  this  option  the  program 
requests  that  the  user  input  the   job  type  number  of  the  job 
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ADD  SERVER  GROUP  RECORD  FUNCTION 

SIMULATION  MODEL  NUMBER:  60 

ENTER  NUMBER  OF  SERVERS  FOR 

SERVER  GROUP  1:  1 

SERVER  GROUP  2  :  1 

SERVER  GROUP  3:  1 

SEEVEE  GROUP  4  :  0 

SERVER  GROUP  5:  0 

SERVER  GROUP  6  :  0 

SERVER  GROUP  7:  0 

SEEVEE  GROUP  8  :  0 

SEPVER  GROUP  9:  0 

(clear  screen) 

(display  of  function  header) 

(display  of  the  servergroup  record) 

DO  YOU  EISH  TO  ADD  THIS  RECORD  ?  Y/- 

Y 

RECORD  SUCCESSFUL  ADDED 

ENIER  ANY  CHAR  TO  RETURN  TO  UPDATE  MENU 


Figure  4- 18    Add  Ser¥ergroup  Record  Dialogue 

type  record  to  be  deleted.  If  the  job  type  does  not  exist  in 
the  data  base  the  following  message  is  displayed : 

NC  EECOFD  FOUND 

otherwise  the  record  is  displayed  and  the  user  is  given  the 
option  of  deleting  it  from  the  data  base.  Depending  en  the 
user  response  the  record  is  deleted  or  not  and  one  of  the 
following  messages  is  displayed: 

RECORD  SUCCESSFULLY  DELETED 


or 


RECORD  NOT  DELETED 
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At  the  end  of  the  function  dialogue  the  user  has  the  option 
of  exiting  function  or  attempting  deletion  of  another  job 
type  record  for  the  same  simulation  model. 

WARNING  : 


t         —                               ... 

WHEN       A    JOB       TYPE    RECORD      IS    DELETED       ALL   THE 

ROUTING 

RECORDS    WHICH       ARE  SUBORDINATED    TO      THAT    J03 

TYPE    ARE 

ALSO    DELETED 

....  

e.      Delete   Routing   Record 

This  option  is  used  to  delete  routing  records  of 
a  simulation  model. 

Upon  selection  of  this  option  the  program 
reguests  that  the  user  input  the  job  type  number  and 
servergroup  number  to  which  the  routing  record  is  attached. 
If  either  the  job  type  record  or  roating  record  are  not 
found  in  the  data  base  an  error  message  is  displayed, 
otherwise  the  user  is  given  the  option  of  deleting  the 
specified  record.  Depending  on  the  user  option  the  record  is 
deleted  or  not  and  one  of  the  following  messages  is 
displayed: 

RECORD    SUCCESSFULLY    DELETED 

or 

RECORD  NOT  DELETED 

At  the  end  of  the  option  dialogue  the  user  is  giver  the 
option  of  exiting  the  function  or  deleting  another  routing 
record. 
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f.  Delete  Server  Group  Record 

This  option  is  used  to  delete  the  server  group 
record  from  the  data  rase. 

Upon  selection  of  this  option  the  program  attempts  to 
locate  th€  server  group  record  in  the  data  base.  If  the 
record  does  not  exist  an  error  message  is  displayed, 
otherwise  the  record  is  deleted  and  the  message 

RECOED  SUCCESSFUIIY  DELETED 

is  displayed.  As  there  is  only  one  server  group  record  per 
simulation  model,  at  the  end  of  the  option  dialogue  aser 
returns  to  Update  Menu  options  by  entering  an  arbitrary 
character. 

g.  Change  Jet  Type  Record 

This  option  is  used  to  change  model  parameters 
stored  into  a  job  type  record. 

The  program  first  requests  that  the  user  input 
the  job  type  number  of  the  job  type  record  to  be  changed.  If 
the  record  does  not  exist  the  following  message  is 
displayed: 

CHANGE  ERROR  JOB  TYPE  NUMBER  NOT  FOUND 

otherwise  the  record  is  displayed  and  the  user  is  given  the 
option  of  selecting  the  model  parameter  to  be  modified, 
arrival  distribution  type,  distribution  parameter,  or  job 
priority.  As  the  user  option  is  entered,  the  program  prompts 
for  input  data  according  to  the  model  parameter  selected. 
When  the  input  is  complete  the  user  has  the  option  to  select 
another  model  parameter  to  be  changed.  If  the  user  chooses 
to  modify  another  parameter  then  the  menu  of  options  for 
changing  of  model  parameters  will  be  displayed  for  another 
function  iteration.    Otherwise  the  entire  updated   job  type 
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record  will  be  displayed  for  user  review.  At  this  point  the 
user  is  given  the  option  of  exiting  the  function  or  changing 
another  job  type  record.  An  example  of  the  user  program 
dialogue  for  changing  a  job  type  record  is  illustrated  in 
Fig  4.19. 

h.   Change  Routing  Record 

This  option  is  used  to  change  the  Hodel 
parameters  stored  in  a  routing  record. 

The  program  first  requests  that  the  user  input 
the  job  type  number  of  the  job  type  record  to  which  the 
routing  record  to  be  changed  is  subordinated  and  then  asks 
the  user  to  identify  the  servergroup  number  of  the  routing 
record.  If  either  the  job  type  or  routing  record  are  not 
found  in  the  data  base  appropriate  error  messages  are 
displayed,  otherwise  the  user  is  given  the  option  of 
selecting  the  model  parameter  to  be  changed,  service 
distribution,  service  distribution  type,  gueueing  discipline 
or  routing  probabilities.  Upon  selection  of  the  model 
parameter  to  be  changed  the  program  prompts  for  entering 
data  according  to  the  option  selected.  When  the  input  of  new 
data  is  complete  the  user  has  the  option  to  change  another 
model  parameter.  If  the  user  chooses  to  change  another 
parameter,  a  new  function  iteration  will  be  processed  for 
the  same  routing  record,  otherwise  the  routing  record  is 
displayed  and  user  is  given  the  option  of  exiting  the 
function  or  changing  another  routing  record. 

An  example  of  the  user  program  dialogue  for 
changing  a  routing  record  is  illustrated  in  Fig  4.20. 

i.   Changing  Server  Group  Record 

This  option  is  used  to  change  the  server  group 
record  for  a  given  simulation  model. 
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1 

*************+***************#***************« 

CHANGE  JCE  TYPE  RECORD  FUNCTION 

SIMULATION  MODEL  SOMBER:   5 

ENTER  NUMBER  OF  JOE  TYPE  TO  CHANGE: 

2 

SIMULATION  MODEL  NUMBER:   5 

JOE 

TYPE  NUMBER:  2 

ARRIVAL  DISTRIBUTION  IS:    EXPONENTIAL 

DISTRIBUTION  PARAMETER  IS:    50 

JCB  PRIORITY  IS:              1 

ENTER  PARAMETER  YCU  WISH  TO  CHANGE 

1-  ARRIVAL  DISTRIBUTION 

2-  DISTRIBUTION  PARAMETER 

3-  JOB  PRIORITY 
2 

ENTER  EXPONENTIAL  EISTRIBUTION  MEAN 

100 

DO 
N 

YOU  WISH  TO  CHANGE  OTHER   PARAMETER  ?  Y/- 

(clear  screen) 

(display  of  function  header) 

SIMUIATION  MODEL  NUMBER  IS:  5 

JOE 

TYPE  NUMBER  IS:  2 

ARRIVAL  DISTRIBUTION  IS:      EXPONENTIAL 

DISTRIBUTION  PARAMETER  IS:        100 

JOB  PRIORITY  IS:                   1 

DO 
Y 

YOU  WISH  TO  EXIT  FUNCTION  ?  Y/- 

Figure  4.19   Changing  Job  Type  Record  Dialogue 

Upon   selection   of   this    option   the   program 
attempts  to  find  the  servergroup  record  in  the  data  base.  If 
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CHANGE  ROUTING  RECORD  FUNCTION 

SIMULATION  MODEL  NUMBER:  60 

ENTER  NUMBER  OF  JOE  TYPE: 

1 

ENTER  NUMBER  OF  ROUTING  RECORD  TO  CHANGE 

1 


SERVICE  DISTRIBUTION  IS 
DISTRIBUTION  PARAMETER  IS 
QUEUEING  DISCIPLINE  IS 


EXPONENTIAL 
19 
FCFS 


ROUTING 
ROUTING 
EOUTING 
ROUTING 
ROUTING 
ROUTING 
ROUTING 
ROUTING 
ROUTING 
ROUTING 


EROB 
PROB 
FROB 
FROB 
EROB 
FROB 
EROB 
FROB 
EROB 
PROB 


TO  1 


TO 
TO 

TO 
TO 
TO 
TO 


IS 
IS 
IS 
IS 
IS 
IS 
IS 


TO  8  IS 
TO  9  IS 
TO  10IS 


97 
0 
0 
0 
0 
0 
0 
0 
0 
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ENTER  PARAMETER  YOt"  WISH  TO 


CHANGE 

1-  SERVICE    DISTRIBUTION 

2-  DISTRIBUTION    TYPE 

3-  QUEUEING    DISCIPLINE 

4-  ROUTING    PROBABILITIES 


ENTER    QUEUEING    DISCIPLINE 

1-FIRST   COME    FIRST    SERVED 
2-LAST    COME    FIRST    SERVED 
3-NONPREMPTIVE    PRIORITY 
4-SHORT.    PROC.    TIME    FIRST 
5-LOW.     WEI. PROC. TIME    FIRST 
6-PROCESSOR    SHARING 
7-SERVICE    IN    RAND.     ORDER 

6 

DO    YOU    WISH    TO   CHANGE    OTHER    PARAMETER    ?    Y/- 

N 

(clear  screen) 
(display  of  function  header) 
(display  of  the  routing  record) 

DO  YOU  WISH  TO  EXIT  FUNCTION  ?  Y/- 

N 


(FCFS) 

*LCFS) 

NP) 

S?T 


tf: 


LWPTF) 

PS) 

SIRO) 


Figure  4-20    Change  Routing  Record  Dialogue 
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the  record  is  not  found  an  error  message  will  he  displayed, 
otherwise  the  number  of  servers  for  each  servergroup  will  be 
prompted.  As  these  data  are  entered  the  updated  servergroup 
record  is  displayed  for  user  review.  The  user  is  returned  to 

the  UPDATE  MENU  by  entry  a  character. 

12.  summary  of  the  Manual  Contents 

This  CPMT  user's  manual  was  primarily  designed  for 
the  CS  4400  students  at  the  Naval  Postgraduate  School.  The 
first  section  introduces  the  simulation  program  to  the  new 
CPMT  users.  As  the  users  should  be  confortable  with  the 
model  design  before  CPMT  utilization,  the  next  section  of 
the  manual  describes  and  illustrates  with  an  example  the 
design  of  simulation  models  to  be  run  by  CPMT.  The  last 
section  explains  how  to  store  and  update  model 
specifications  in  the  simulator  data  base,  and  run  a 
simulation.  Some  examples  of  the  user  program  dialogue  are 
displayed  for  easier  familarization  with  the  simulator. 
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7.  TESTING  ANP  liLIDATION 

The  objective  in  this  chapter  is  to  validate  the  CPMT 
ability  to  simulate  computer  systems.  To  accomplish  this 
validation  a  set  of  testing  models  was  run  and  the  output 
results  analyzed.  The  characteristics  of  the  testing  models 
include  CEMT  capabilities  not  analyzed  by  Lt  Pagel  [Bef.  2] 
and  additional  enhancements  implemented  through  this  thesis 
effort. 

The  criteria  and  procedures  used  for  validation  are 
described  in  the  first  section,  followed  by  a  description  of 
each  experiment  and  an  interpretation  of  the  collected  data. 
A  summary  of  conclusions  is  presented  at  the  end  of  the 
chapter. 

1 .   Criteria 

The  overall  criterion  used  for  CPMT  validation  was 
that  the  conclusions  that  are  drawn  from  running  a 
simulation  model  on  the  simulator  should  be  the  same 
conclusions  that  would  have  been  drawn  from  evaluating  the 
model  in  analytical  form. 

A  random  sample  of  10  (n)  measurements  of  each  output 
parameter  is  collected  from  independent  simulation  runs. 
Based  on  this  sample,  a  two  tailed  hypothesis  test  is 
performed  or  the  mean  value  to  decide  whether  the  simulation 
results  come  from  the  same  population  as  the  analytical 
re  s  u  1 1  s . 

levels  of  significance  of  .05  and  .01  were 
established  as  acceptable  accuracy  bounds.  As  the  sample  is 
small,  it  was  assumed  to  come  from  a  student-t  distribution 
with  9  (n-1)  degrees  cf  freedom. 

The  null  hypothesis  is  the  following  : 
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H  :  /*    =yU„ 

where  is  the  sample  mean  and  is  the  analytical 
parameter.  The  alternative  hypothesis  is  : 

H  :  /*  /*/*c 

The  critical  values  obtained  from  the  t-statistical  tatle 
for  the  levels  of  significance  and  degree  of  freedom 
descriled  atove  are  listed  in  Table  II. 


TABLE  II 
Critical  Values  froa  T-statistical  Table 


LEVEL  OF  CRITICAL 

SIGNIFICANCE  VALUE 


0.05  1.833 

0.01  2.821 


Ihe    sample    mean  is  transformed  to  student-t    distribution 

by   equation   5.  1    ,    where        is   the   analytical   parameter,    S   the 
sample    standard    deviation   and   n  the   sample   size. 

t   =    (  x  -yuc)/    (S   /  \Tn)  (egn   5.1) 

For  a  given  sample  the  null  hypothesis  is  rejected 
if  the  statistic  computed  from  equation  5.1  is  greater  than 
the  critical  value  for  the  level  of  significance  teing 
considered.  Otherwise  the  null  hypothesis  is  accepted. 
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2  •   l§st  Case  jM 

a.  Objective 

The  objective  is  to  test  the  simulator  behavior 
for  a  deterministic  service  rate  and  independent  service 
demand  gueueing  discipline  (FCFS,  LCFS  or  SIRO) .  The  output 
parameter  to  be  measured  is  the  system  throughput. 

b.  Simulaticn   Model 

The  simulation  model  consists  of  a  single  server 
gueueing  model  in  which  the  arrival  rate  is  exponentially 
distributed  and  the  service  rate  is  constant  (M/D/1).  The 
interarrival  mean  and  service  mean  are  100  and  50 
respectivelly.  The  model  is  to  be  run  independently  for 
FCFS,  LCFS  and  SIRO  gueueing  disciplines. 

c.  Simulaticn  Results 

The  simulation  run  duration  was  specified  by  the 
number  of  jobs  to  be  processed  and  the  output  results  are 
listed  in  Table  III. 

d.  Analytic  Besults 

The  system  throughput  for  a  single  server  model 
is  egual  to  the  arrival  rate.  As  the  interarrival  mean  for 
the  mcdel  is  100  the  arrival  rate  and  throughput  rate  are 
egual  to  0.01. 

e.  Statistical  Analysis 

The  mean  and  standard  deviation  of  the  system 
throughput  obtained  from  the  samples  are  listed  in  Table  IV. 
The  values  of  the  statistic  computed  from  equation  5.1  using 
the  mean  and  standard  deviation  listed  in  Table  IV  are 
1.941,  2.395  and  2.678  for  FCFS,  LCFS  and  SIRO  gueueing 
disciplines. As    these    values    are    less    than    the   critical    value 
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RUN 
# 

1 
2 
3 
4 
5 
6 
7 
8 
9 
10 

TABLE 
Simulation  Results 

NUMBER                              TI 
JOBS                 FCFS 

III 

;  of   Test   Case   #1 

50UGHPUT    RATE 
LCFS 

0.0100 
0.0100 
0.0101 
0.0099 
0.0099 
0.0099 
0.0100 
0.0100 
0.0099 
0.0099 

SIRO 

15000              0.0100 
55000              0.0100 
22000              0.0099 
78000              0.0100 
34000              0.0100 
61000              0.0100 
92000              0.0099 
27000              0.0100 
100000              0.0100 
84000              0.0100 

0.0100 
0.0100 
0.0100 
0.0100 
0.0100 
0.0100 
0.0099 
0.0099 
0.0099 
0.0100 

T1BLE   If 
Hean    and  Std*  for   Test  Case  #1 


DISCIPLINE 

MEAN 

STAND. DFV. 

[                                             FCFS 

0.00998 

0.0000327 

LCFS 

0.00996 

0.0000527 

SIRC 

0.00997 

0.0000353 

for  the  0.01  level  of  significance  (2.821),  the  null 
hypothesis  is  accepted  for  all  the  gueueing  disciplines. 
However  as  the  same  statistics  are  greater  than  1.833  the 
null  hypothesis  is  rejected  for  all  the  cueueing  disciplines 
if   the    0.05   level    of    significance   is    to   be    considered. 


98 


3 •   l§st  Case  #2 

a.  Objective 

The  objective  is  to  test  CPMT  for  simulation  of 
multiple  servers  within  a  servergroup.  The  parameter  to  be 
measured  is  the  mean  number  of  jobs  in  the  system. 

b.  Simulation  Model 

The  simulation  model  consists  of  a  M/M/2 
gueueing  model  with  a  mean  interarrival  rate  of  20  and  a 
mean  service  rate  of  10. 

c.  Simulaticn  Results 

The  simulation  run  duration  was  specified  by  the 
number  of  events  to  be  processed  and  the  output  results  are 
listed  in  table  V. 


TABLE  V 
Simulation  Results  of  Test  Case  #2 


RUN 

NUMBER 

MEAN  NUMBER 

# 

EVENTS 

JOBS 

1 

25000 

0.526 

2 

43000 

0.561 

3 

127000 

0.530 

4 

99000 

0.561 

5 

63000 

0.530 

6 

85000 

0.529 

7 

178000 

0.539 

8 

134000 

0.517 

9 

225000 

0.515 

10 

165000 

0.543 
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d.  Analytic  Besults 

The  mean  number  of  jobs  in  the  system  for  the 
M/M/2  model  is  described  ty  equation  5.2  where  the 
utilization  U  is  computed  from  equation  5.3  .  The 
utilization  obtained  from  the  last  equation  using  the  mean 
values  of  the  model  is  0.25.  Substituting  this  value  in 
equation  5.2  we  get  0.533  as  the  mean  number  of  jobs  in  the 
system. 

E(N)  =  2*U  /(1-  02)  (eqn  5.2) 

0  =  service  mean  /  (2  *  interarrival  mean)       (eqn  5.3) 

e.  Statistical  Analysis 

The  mean  and  standard  deviation  of  the  number  of 
jobs    in    the  system    for   the   samples   shown   in   Table   V   are    : 

MEAN  STANDARD    DEVIATION 

0.535  0.016 

The  statistic  obtained  from  equation  5.1  using  the  mean 
and  standard  deviation  listed  above  is  0.4.  As  this  value  is 
less  than   the  critical  values  from   Table  II  ,  (1.833  and 

2.821)  the  null  hypothesis  is  accepted  for  0.05  and  0.0  1 
levels  of  significance. 

4-   l^st  Case  13 

a.   Objective 

The  objective  of  this  experiment  is  to  study  the 

CPMT  behavior  when  sinulating  jobs  with  different  priorities 

and  served  by  a   non preemptive  priority  queueing  discipline. 

The   output   to  be   measured   is   the   mean  time   in   system 

(response  time)  . 
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b.   Simulation  Model 

The  model  consists  of  a  single  server  gueueing 
model  in  which  arrivals  and  service  time  occur  randomly  with 
an  exponential  distribution.  The  workload  is  partitioned 
into  three  classes  of  jobs.  Each  job  type  has  a  given 
priority,  mean  interarrival  time  and  mean  service  time,  as 
listed  in  Table  VT. 

Jobs  are  served  in  a  nonpre-erati ve  priority 
schedule. 


TABLE  VI 
Characteristics  of  each  Standard  Type  of  Job 

JCB  TYIE   PRIORITY    MEAN  INTERARRIVAL     MEAN  SERVICE 


1  1  200  50 

2  2  500  125 

3  3  2000  500 


c.  Simulation  Results 

The  simulation  run  duration  was  specified  by 
simulation  time  and  the  sample  of  output  results  is  listed 
in   Table  VII. 

d.  Analytic    Besults 

The  mean  response  time  for  all  jobs  and  for  each 
job  type  for  this  model  are  taken  from  [fief.  1  :p.77],  and 
are    shown  in  Table   VIII. 
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TABLE    ¥11 

Simulation  Results   of   Test 

Case  #3 

RON 

SIMUL 

MEAN    TIME 

IN 

SYSTEM 

* 

TIME 

AIL 

TYPE    1 

TYPE    2 

TYPE    3 

1 

123000 

5C5.8 

291.8 

611.4 

2311.8 

2 

155000 

410.5 

250.4 

51  1.8 

1623.1 

3 

240000 

438.0 

265.2 

574.9 

1698.3 

4 

430000 

482.6 

294.4 

597.9 

1888.6 

5 

762000 

499.6 

296.8 

628.6 

2038.4 

6 

261000 

490.1 

295.  1 

588.8 

2046.  1 

7 

943000 

397.1 

243.1 

529.4 

1423.  1 

8 

335000 

478.9 

282.3 

604.3 

1984.7 

9 

433800 

452.2 

272.2 

565.2 

1785.2 

10 

692000 

457.3 

267.0 

583.7 

1847.0 

_ 

TABLE    VIII 

Analytical  Solution   of  Test  Case  #3 

TYPE 

EESPONSE    TIME 

ALL 

460 

1YPE    1 

275 

TYPE    2 

575 

TYPE    3 

1850 

e.   Statistical  Analysis 

The  mean  and  standard  deviation  of  response  time 
for  the  samples  are  listed  in  Table  IX. 
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■ 

....         . 

TABLE 

IX 

Bean  an 

d  Stdv  for 

Test  Case  #3 

JOB  TYPE 

MEAN 

STANDARD  DEVIATION 

I            ALL  JOBS 

461.2 

37.  1 

1            TYPE  1 

275.  8 

19.4 

f           TYPE  2 

579.6 

36.2 

|           TYPE  3 

1864. 6 

250.  7 

i 

..  _..     _  _  _.. 

The  statistic  values  computed  from  equation  5. 1  using  the 
mean  and  standard  deviation  listed  in  Table  IX  are  0.1 , 
0.04,  0.40  and  0.18  for  all  jobs  and  for  each  job  type.  As 
these  values  are  less  than  the  critical  values  1.833  and 
2.821  the  null  hypothesis  is  accepted  for  all  jobs  and  for 
each    job  type   for   0.C5   and    0.01   levels   of    significance. 

5-      lest  Case    #4 

a.  Objective 

The  objective  of  this  experiment  is  to  test  CPMT 
for  simulation  of  closed  network  gueueing  models.  The  output 
parameters   to   be   measured  are   the    server    utilizations. 

b.  Simulation   Model 

The  simulation  model  consists  of  a  closed 
gueueing  central  server  model  which  was  already  described  in 
detail  in  Chapter  4  of  this  thesis. 

c.  Simulaticn  Results 

The  simulation  run  was  specified  by  simulation 
time  and  the  output  results  are  listed  in  Table  X. 
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TABLE    X 

■ 

Simulation 

Results   of 

Test   #4 

RUN 
ft 

SIMULATION 

TIME 

CPU 

UTILIZATIONS 
HARD 

FLOPEY 

1 

2 
3 
4 
5 
6 
7 
8 
9 
10 

133000 
411000 
325000 
127000 
251000 
531000 
301000 
210000 
442000 
536000 

0.  948 
0.953 
0.966 
0.967 
0.937 
0.  968 
0.939 
0.  864 
0.957 
0.974 

0.  416 
0.416 
0.  403 
0.449 
0.409 
0.423 
0.443 
0.360 
0.449 
0.436 

0.343 
0.339 
0.347 
0.310 
0.346 
0.343 
0.343 
0.340 
0.335 
0.332 

_.i 

d.   Analytic  Results 

The  numerical  solution  for  the  model  computed  by 
the  IBM  software  simulation  package  RASQ,  according  to 
LAVENBERG  [Bef.  1  :p.378]r  estimates  the  following  server 
utilizations  ; 

CPU  0.95 

HARD  DISK 0.42 

FLOPPY  DISK...  0.33 


e.   Statistical  Analysis 

The  mean  and  standard  deviations  for  the  server 
utilizations  obtained  from  the  sample  are  listed  in  Table 
XI. 


104 


TABLE    XI 
Hean    and   Stdv   for   Test  Case   #4 

SERVER  MEAN  STANDARD    DEVIATION 

CPU  0.947  0.017 

HARD    DISK  0.420  0.027 

FLOPPY    DISK  0.337  0.011 


The  statistics  computed  from  equation  5.1  using 
the  mean  and  standard  deviations  listed  in  table  XI  are  0.57 
,  0  and  2.23  for  CP0,  HARD  DISK  and  FLOPPY  DISK.  As  all 
these  values  are  less  than  the  critical  value  for  the  0.01 
level  of  significance  (2.82  1),  the  null  hypothesis  is 
accepted  for  all  server  utilizations.  For  the  0.05  level  of 
significance,  as  the  critical  value ( 1. 833) is  less  than  the 
statistic  found  for  the  FLOPPY  DISK  utilization  (2.23)  and 
greater  than  the  values  found  for  CPU  and  HARD  DISK  (0.57 
and  0),  the  null  hypothesis  is  rejected  for  the  first  server 
and   accepted   for    the   last   two   servers. 

This  result  is  not  surprising  because  the 
branching  probabilities  assigned  to  the  CPHT  model  were 
rounded    from  the   original  model. 

6-      l^st   Case   #5 

a.      Objective 

The  objective  of  this  test  case  is  to  estimate 
the  CPMT  performance  for  simulation  of  more  complex  models. 
To  accomplish  this  estimation  a  hypothetical 

terminal-oriented  distributed  computing  system  was  modeled. 
The  parameters  to  be  measured  are  the  system  throughput  and 
mean    time   in  system. 
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t.   The  System 

The  computer  system  to  be  modeled  was  adapted 
from  1EI7EDI  £Hef.  3  :p-441],  and  it  is  a  distributed  system 
vhich  primarily  services  three  5  terminals  (T)  .  The  system 
includes  four  processors,  a  front-end  (F) ,  a  communication 
processor  (C) ,  a  DBMS  processor  (D)  and  the  principal 
element  processor  (P)  - 

A  single  class  of  jobs  is  processed  and  there  is 
one  job  assigned  to  each  terminal.  The  branching 
probabilities  are  described  by  the  matrix  in  Figure  5.1. 


T 

F 

c 

D 

p 

T 

0 

1 

0 

0 

0 

F 

0.8 

0 

0 

.2 

0 

0 

C 

0 

0. 

.458 

0 

0. 

,333 

0.209 

D 

0 

0 

1 

0 

0 

P 

0 

0 

1 

0 

0 

Figure  5.1    Branching  probabilities  Hatrix 

The  average  think  time  of  a  terminal  and  the 
average  service  times  for  the  processors  are  assumed  to  be 
exponential  distributed  with  the  mean  values  as  listed  in 
Figure  5.2. 

c.   Simulaticn  Model 

The  model  consists  of  a  closed  queueing  network 
with  five  nodes.  A  jcb  spends  a  think  time  at  the  terminal, 
traverses  the  subnetwork  of  processors  and  when  it  completes 


-A  small  number  of  terminals  was  simulated  to  facilitate 
the  analytical  solution 
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■i 

SERVER 

AVERAGE    TIME 

TERMINAL 

15    sec. 

PROCESSOR    F 

0.67    sec. 

PROCESSOR   C 

1    sec. 

PROCESSOR    D 

5    sec. 

PROCESSOR   P 

5    sec. 

Figure  5.2    Average  Think  and  Service  Times 

has  another  think  time-  Each  processor  is  modeled  ty  a 
servergroup  with  a  single  server.  The  set  of  terminals  is 
modeled  by  a  servergroup  with  multiple  servers.  The  CPMT 
model  and  servergroup  data  form  are  illustrated  in  Figures 
5-3  and  5.4. 

Because  the  smallest  time  is  in  the  0.0  1  sec 
range,  see  Fig  5.2  ,the  time  values  are  multiplied  by  100 
for  routing  record  data  input.  As  the  routing  probatilies 
from  a  given  servergroup  must  te  represented  as  integers  and 
the  sum  must  be  egual  to  100,  the  probabilities  from  the 
branching  matrix  shewn  in  Figure  5.1  are  rounded  to  meet 
this  criterion.  The  job  type  and  routing  record  data  form 
for  the  model  are  illustrated  in  Figure  5. 5. 

d-   Simulation  Results 

The  simulation  run  was  specified  by  simulation 
time  and  the  output  results  6  are  listed  in  Table  XII. 


&Cutput  values  are   divided  by  100  to  convert   to  1  sec 
time  unit 
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Figure  5. 3    Simulation  Model  of  Test  Case  #5 


1 

Simulation 

Number 

. 

99 

Servergroup 

Num  ber 

• 

Num 

ber 

of 

Servers    : 

1 

3 

2 

1 

3 

1 

4 

1 

5 

1 

6 

0 

7 

0 

8 

0 

9 

0 

Figure  5.4    Servergroup  Data  Form  for  Test  Case  #5 
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Simulation  Number 
***************** 

Arrival  Dist 

Cist  Param 

Priority     :  1 
**************** 


99       Job  Type  Number  :  1 
JOB  TYPE  RECORD   *************** 


Servergroup 
Service  Dist 
Cist  Param 
Queue  Disc 


ROOTING       RECORD       ***************** 
0123456789 
-22222 
-    1500    67    100    500    500 
-11111 


Routing  To 

SG  1 

100   - 

80 

— 

—    — 

SG    2 

-  100 

— 

46 

—    — 

SG  3 

—   — 

20 

— 

100  100 

SG    4 

—   — 

— 

33 

—    — 

SG    5 

—   — 

— 

21 

—    — 

SG    6 

SG  7 

SG    8 

SG  9 

Figure   5.5        Job   Type  and  Bouting   Record   Data  Form   of   Test   #5 

e.      Analytic    Eesults 

The  analytic  procedure  used  to  solve  the  network 
model    was   extracted    from   TRIVEDI   £Ref.    3]. 

From  the  branching  probabilities  listed  in  Fig 
5. 1  we  get  the  following  system  of  linear  equations  for 
computation  of  relative  throughputs  V ;  *  s  of  the  network 
noies    : 

vT=    VF*   0.  8 

V  =    v    +    V    *    0.458 

FTC 

V  =  Y   *   0.2   +    v  ♦   70 

V  =   V    *   0. 333 
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TABLE  III 
Simulation  Results  of  Test  Case  #5 


UN 

SIMULATION 

TRHOUGHPUT 

MEAN  TIME 

# 

TIME 

RATE 

IN  SYSTEM 

1 

2981300 

0-  16 

18.707 

2 

17804CC 

0.16 

18. 322 

3 

3173500 

0.  16 

18.211 

4 

234600 

0.17 

17.941 

5 

1995000 

0.  17 

17.763 

6 

23421CC 

0.16 

18.401 

7 

3812000 

0.  17 

17.973 

8 

890000 

0.17 

17.883 

9 

5678800 

0.  16 

18. 199 

10 

212000C 

0.17 

18.074 

V    =    V    *    0. 209 

P  c 


Choosing    VT=      1    and    solving    the   system   of      equations   we    find 
the    following   relative   throughput   for   the   remaining   nodes   : 


Vp=    1.25 


Vc=   0.546 


V    =    0.182 


Vp=    0.114 


The  relative  utilization  of  node  i  is  given  by  the  equation 
5.4    where    Vt-    is    the    relative   throughput    and    E  (S)    the   service 

time. 

p.=    v^*    E(S)  (eqn    5.4) 

Substituting  the  service  times  from  figure  5.2  and 
throughput  in  eguaticn  5.4  we  get  the  following  relative 
utilizations    : 
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(V=  0.83 

(1C=  0.54 

f,=  0.90 

PP=  0-57 

The  average  system  throughput  is  given  by  equation  5.5  where 
M  is  the  number  of  terminals  and  C  is  the  normalization 
constant. 


TRCUGHGHPUT  =  C(M  -  1)/C(fi) 


(egn    5.5) 


The  computation  cf  normalization  constants  is  performed  by  a 
recursive  scheme  based  on  the  equations  5.6  ,  5.7  and  5.8  , 
where  c  is  the  number  of  servers  at  node  i,  and  Bi.(kt-)  the 
joint    probability    of    k      jobs   at    node    i. 


0.     (K.J  =  ^       ' 


qic; 


K>;C 


(eqn    5.6) 


R.fK)     = 


Pi/BxM         K*0 


I 


K-0 


(eqn    5.7) 


RoU) 


C\0)  =         "° 


(  2Tc  a-*.)/* ov   ,v 

I  I- 1 


R0  CJJ 


,s    0 


(eqn    5.8) 


The  values  obtained  for  C(2)  and  C (3)  are  160.16  and  965.8. 
Substituting  these  values  in  eguation  5.5  we  found  0.166  as 
the    analytic  troughput   rate. 
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The    analytic   response      time    is   obtained   from    the 
equation 

RESPONSE    TIME    =    M    /    TROUGHEUT   -    THINK    TIME 

Substituting  the  number  of  terminals  3,  throughput  0.166  and 
think  time  15  sec-  in  the  equation  above,  we  get  3.116  sec. 
as  the  analytic  response  time.  As  the  parameter  tc  be 
compared  is  the  mean  time  in  the  system  we  have  to  add  the 
average  think  time,  15  seconds  to  this  value  to  find  the 
analytic  result    which  is    18.116   sec. 

f.      Statistical   Analysis 

The      sample      mean     and      standard     deviation      for 
throughput  and   mean    time   in   system   are   listed   in    Table    XTII 


TABLE    XIII 
Mean    and  Stdv  of  Test   Case   #5 

TRCUGHPUT  TIME    IN    SYSTEM 


MEAN  0.165  18.147 

STDV  0.005  0.427 


The  statistics  obtained  from  equation  5. 1  using  the  values 
of  Table  XIII  are  0.625  and  0.23  for  throughput  and  response 
time.  As  these  statistics  are  less  than  the  critical  values 
for  the  0.01  and  0.C5  levels  of  significance  (2.821  and 
1.833),  the  null  hypothesis  is  accepted  for  both  accuracy 
tounds. 
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"7  •   Conclusions 

From  the  results  of  statistical  tests  performed  on 
the  population  mean  for  different  output  parameters  and 
simulation  models  we  conclude  that  the  simulation  results  do 
not  differ  significantly  (at  0.0  1  and  0.05  levels  of 
significance)  from  what  would  be  the  analytic  results. 

The  accuracy  of  results  could  be  improved  by 
extending  the  precision  of  the  branching  probabilities  to 
bring  them  in  closer  correlation  with  the  simulated  systems. 

The  complexity   of  the  analytic  procedure   which  was 
required  to   obtain  numerical  solution  for   the  perfornance 
parameters   of    the   distributed    sytem   (Test    Case   #5) 
illustrates  the  advantage  of  using  simulation  techniques  for 
evaluation  cf  computer  systems. 
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¥1.  CONCLUSION 

Maintenance  of  a  software  product  is  considered  to  begin 
from  the  time  that  the  program  becomes  operational  and  is 
primarily  concerned  with  changes  to  reflect  expansion  of 
reguirements.  This  thesis  was  intended  for  enhancement  of  an 
operational  simulaticn  program  (CPMT)  in  areas  such  as 
modeling  capability  ,  simulation  run  flexibility,  processing 
efficiency  and  user  friendliness. 

A  new  class  of  gueueing  network  models,  closed  network, 
and  five  additional  gueueing  disciplines,  Last  Come  First 
Serve,  Serve  in  Randcm  Order,  Nonpreemptive  Priority,  Short 
Processing  Time  First,  and  Weighted  Short  Processing  Time 
First  were  made  available  in  the  new  version  of  CPMT  to 
increase  the  modeling  flexibility.  However  further 
enhancement  could  be  done  in  this  area.  Extension  of  the 
network  aodels  in  order  to  include  multiple  sources  and/or 
sinks,  and  passive  gueues  are  examples  of  potential  topics 
for  enhancement.  Assunptions  of  the  simulator  design  such  as 
the  server  be  always  serving  a  job  when  jobs  are  present  and 
infinite  capacity  of  the  servergroups  may  not  be  true  in 
some  model  applications  and  therefore  they  can  also  be  the 
object  of  research.  Finally,  pre-erative  gueueing  disciplines 
such  as  last  Come  First  Served  Preemptive  Resumed  (LCFSPR) 
and  Preemptive  Priority  (PP)  are  not  implemented  and  could 
be  useful  for  modeling  of  some  real  systems. 

The  modified  program  provides  alternative  methods  of 
specifying  the  simulation  run  duration.  Simulation  time  and 
number  of  events  to  be  processed  are  new  options  to  define 
the  period  of  time  a  simulation  is  to  be  run. 

The  memory  reguirements  of  the  program  were 
significantly  reduced  by  changing   the  space  complexity  of 
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the  algorithm  for  job  generation.  Sizable  simulations  can  be 
run  in  the  new  version  without  any  system  limitation. 

A  large  number  of  changes  was  introduced  in  the  program 
operation  in  response  to  criticism  of  CPMT  users  and  as 
result  of  our  intensive  utilization  of  the  program.  The 
evaluation  of  the  current  program  user  friendliness  can  only 
be  done  ly  further  CPMT  utilization. 

The  accuracy  of  the  results  was  discussed  in  detail  in 
the  last  chapter  and  demonstrates  the  CPMT  ability  to 
simulate  computer  systems  represented  by  open  or  closed 
gueueing  network  models.  Further  it  has  been  demonstrated 
that  the  time  and  work  required  for  computer  modeling  and 
simulation  using  CPMT  are  relatively  constants  regardless  of 
the  complexity  of  the  simulation  models  to  be  run. 
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